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

[Alan Ruttenberg]

Clozure CCL's behavior is more complicated and confusing.

Without keywords directory doesn't return the file *at all* while
truename fails saying that the file does not exist.

However it also has keywords :include-emacs-lock-files and :follow-links

With :include-emacs-lock-files t and :follow-links nil it directory
returns the problematic entry's name, and with :follow-links t (or not
supplied) it gives an error.

I would be satisfied with this behavior as well, though I think SBCL's
is cleaner.

The problem with ABCL's function is that there is no way to avoid
getting an error when applying directory to it.

-Alan

On Tue, Jan 7, 2014 at 1:40 PM, 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.
>
> I'm downloading ccl to see what it does.
>
> -Alan
>
>
> On Tue, Jan 7, 2014 at 5:05 AM, Marco Antoniotti <marcoxa at cs.nyu.edu> wrote:
>> Hello,
>>
>> as anything that deals with PATHNAMES is inherently a “hic sunt leones” area.
>>
>> My suggestion - as a user! - regarding this TRUENAME issue is that the top confer is to minimize differences with other implementations.  Another suggestion would be to see what Farè’s UIOP library is doing in this case.
>>
>> Cheers
>> —
>> MA
>>
>>
>>
>> On Jan 6, 2014, at 18:30 , Alan Ruttenberg <alanruttenberg at gmail.com> wrote:
>>
>>> Emacs creates files like this:
>>> lrwxr-xr-x   1 alanr  staff     30 Jan  6 01:40 .#foo.sql@ ->
>>> alanr at conjunctive-2.local.6427
>>>
>>> as lock files, IIRC.
>>>
>>> In such cases, the target of link names a file that doesn't exist.
>>> #'directory calls #'truename on the filenames that are listed, and
>>> truename does a probe file. Incidentally It looks like that is done in
>>> the java as well as the lisp function making the latter redundant.
>>>
>>> It seems wrong that there is a situation in which one can't call
>>> directory at all without getting an error.
>>>
>>> The crux of the matter is how to interpret the documentation of
>>> truename in the presence of symbolic links.  The doc for truename
>>> says:  If filespec is a pathname it represents the name used to open
>>> the file. This may be, but is not required to be, the actual name of
>>> the file."
>>>
>>> "actual name of the file" suggests that there is a file, but also
>>> suggests that it is the name that is important. Also whereas directory
>>> allows implementation-dependent keywords, truename is not so defined.
>>>
>>> I'll take the position that truename should *not* depend on the file
>>> existing, but rather focus on what names are present in directory
>>> structures. So resolve-truenames nil should should return the names in
>>> the directory and for resolve-truenames t it should follow symbolic
>>> links as long as they can be followed without hitting a name that
>>> doesn't designate an existing file.
>>>
>>> -Alan
>>
>> --
>> Marco Antoniotti
>>
>>
>>