[Openmcl-devel] Directory and symlinks

[Gary Byers]

If only there was a language specification that gave us at least some
guidelines as to what to expect, we wouldn't have to all announce what
our intuition leads us to expect (for DIRECTORY or a few hundred other
things.)

Oh wait ... there is such a spec.  What it says about DIRECTORY's behavior
uses terms like "matching" and "present in the file system" without fully
defining those terms.

CCL, SBCL, AllegroCL, and LispWorks (at least the versions that I have)
interpret those terms differently than you apparently do.  If you think
that that interpretation of what the spec actually says is wrong, I'd
be interested in hearing why.  (Substantially more intetrested than I
am in hearing a bunch of people say "I expect ...".)  I don't always
expect SORT to destructively modify its argument, but if I read the spec
I should expect that; my expectations (except as they pertain to the spec)
aren't too interesting.

If the spec had said (of DIRECTORY) that it determines the set of files
whose TRUENAMEs match, then there'd be a strong basis for your expectation.
What it does say strongly suggests that TRUENAME is used in producing the
result from a set of matching files but not in determining the elements
of that set.  (/usr/local/src/ccl isn't "present in the filesystem" in
my home directory; a file whose TRUENAME is /usr/local/src/ccl is.)

I think that that's the best interpretation of what the spec actually
says.  I don't think that it's quite as cut-and-dry as it is in the
case of SORT's destructive behavior, but I think that that
interpretation is substantially better than one that supports your
expectation (and that someone who doesn't TRUENAME to be used in
matching and instead gets results like those that you say you expect
has a pretty strong basis for considering that to be a bug.)

That's a totally separate question from "what SHOULD the spec have said ?"
or "if you could choose between resolving links while matching or only
doing so while returning a result, which behavior would be more useful
more often ?" Unlike the case with SORT, DIRECTORY can be extended with
implementation-dependent keyword arguments, and an argument that says
"resolve links while matching" would certainly be useful.




On Wed, 9 Nov 2011, Waldek Hebisch wrote:

> Gary Byers wrote:
>>
>> On Wed, 9 Nov 2011, Zach Beane wrote:
>>
>>> Gary Byers <gb at clozure.com> writes:
>>>
>>>> On a Linux system, my home directory is "/home/gb" and CCL is installed
>>>> in "/usr/local/src/ccl". If I do (in the shell):
>>>>
>>>> $ cd
>>>> $ ln -sf ../../usr/local/src/ccl .   # also tried absolute name here
>>>>
>>>> and in CCL:
>>>>
>>>> ? :pwd                          ; can also call (CCL:DEFAULT-DERECTORY)
>>>> #P"/home/gb/"
>>>> ? (directory "ccl/*/*.lx64fsl")
>>>> => list of .lx64fsl files in immediate subdirectories of CCL directory.
>>>>
>>
>> No, and there's at least some argument that it shouldn't.  (I'm not absoulutely
>> sure that I believe that argument ...)
>
> Well, I expect that (directory "*/*/*.lx64fsl") returns the things
> that (directory "ccl/*/*.lx64fsl") returns plus maybe soemthing
> more.  But with ccl this does not work.
>
>> The argument is that DIRECTORY is supposed to find matching files that are
>> present in the filesystem and return their truenames.  Does "foo" (or "ccl")
>> match the first wildcard in the argument to (directory "*/*.image") ?  The
>> truenames of those links clearly do, but it's less clear that the links themselves
>> do.  (I can imagine wanting both behaviors.)
>
> This argument applies equally to "*/*.image" and "ccl/*.image".
>
> --
>                              Waldek Hebisch
> hebisch at math.uni.wroc.pl
>
>