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

Mark Evenson evenson at panix.com
Fri Jan 10 11:44:03 UTC 2014


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








More information about the armedbear-devel mailing list