There are, I would offer, several arguments suggesting that the
current behavior should not be the default.

My conclusion:
- If resolve-symlinks is false, the behavior should be either that of
SBCL's (return the name) or CCL's (don't return the name) depending on
which answer the implementation takes towards the question "is a
symbolic link a file?".
- If resolve-symlinks is true then signal an error.
- The default should be :resolve-symlinks nil, because cognate
directory operations in every operation's default case that I'm aware
of is to not consider this case an exception.

Regarding CCL's application-specific reference to emacs, I simply
think the argument is named poorly. In fact directory will return
paths to any links that do not resolve, not only emacs lock files.  A
better argname would be :include-unresolvable-links.

This email was tool long :)

-Alan

On Fri, Jan 10, 2014 at 6:44 AM, Mark Evenson <evenson@panix.com> wrote:
>
> On Jan 7, 2014, at 19:40, Alan Ruttenberg <alanruttenberg@gmail.com> wrote:
>
>> Well, SBCL returns the name of the directory entries(without resolving
>> symbolic links) when I use the directory function and truename returns
>> the directory entry unmolested for the  problematic entry. I guess
>> sbcl precedes Faré ;-)
>>
>> Note this is despite the fact that sbcl also has a :resolve-symlinks
>> argument to directory, and that it also defaults to true.
>>
>> I think this should be the behavior for ABCL, with the resolving and
>> probing separated altogether from the truename and directory code.
>>
>
> It is [quite clear from the Hyperspec][DIRECTORY] that DIRECTORY "returns a fresh list of pathnames corresponding to the truenames of those files.”
>
> And it is [quite clear as well][TRUENAME] that calling TRUENAME on a non-existent file should signal a file error.
>
> What is not clear is whether the “fresh list of pathnames” returned by DIRECTORY is the actual result of calling TRUENAME on the filespec.  I guess it doesn’t have to be, which is what SBCL and CCL seem to be implementing.
>
> I guess I am leaning towards adding a further arg to DIRECTORY “:RESOLVE-ENTRIES-VIA-TRUENAME” (terrible name, should be shorter) which defaults to NIL, which would preserve the current behavior.  Otherwise, we would treat symbolic links in the same manner as SBCL:  populate the PATHNAME with what would be used in making a TRUENAME call, but don’t actually make the call.
>
> Adding an application specific (“ignore Emacs backup files”) mechanism like CCL to the Common Lisp part of things smells wrong: one should at least implement the rudiments of an extensible API that would allow other filespecs to be added to the list of directory entries to be treated in this manner.
>
> But I do think that the ANSI spec intends that once one has the results of the DIRECTORY call, and the relevant parts of the filesystem are not changed in the meantime, applications expect that the results remain valid TRUENAMEs (i.e. they can be accessed).
>
> In practice, I guess this is why everyone has their own toolsets for dealing with filesystems.
>
> Comments?
>
>
> [DIRECTORY]: http://www.lispworks.com/documentation/HyperSpec/Body/f_dir.htm
> [TRUENAME]: http://www.lispworks.com/documentation/HyperSpec/Body/f_tn.htm
>
> --
> "A screaming comes across the sky.  It has happened before but there is nothing
> to compare to it now."
>
>
>
>
>