[armedbear-devel] undesirable behavior in #'directory ?

[Alessio Stalla]

On Fri, Jan 10, 2014 at 3:51 PM, Alan Ruttenberg
<alanruttenberg at gmail.com>wrote:

> 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.
>

I agree wholeheartedly. CL's filesystem handling is already bad as it is
without implementation-specific warts.


> 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 at panix.com> wrote:
> >
> > On Jan 7, 2014, at 19:40, Alan Ruttenberg <alanruttenberg at 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."
> >
> >
> >
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/armedbear-devel/attachments/20140110/5e6d0a77/attachment.html>