[pg-cvs] osicat dotted-namestrings and absolute-pathname interaction around directory iterators

[Nikodemus Siivola]

On 22 August 2011 01:44, MON KEY <monkey at sandpframing.com> wrote:

> Maybe, but these also seem braindamaged:
>
>  (osicat:absolute-pathname ".")
>  ;=> #P"/home/bubba/quux/."
>
>  (osicat:absolute-pathname "..")
>  ;=> #P"/home/bubba/quux/.."

I think I agree. I'll need to think on this -- and the split in
responsibility between the host lisp and CL some more, though.

>> 1. Assuming current directory contains a single file "foo.txt", what
>> would you like (osicat:list-directory ".") and (osicat:list-directory
>> "./") to return?
>
> I will answer your question with the proviso that I am currently given
> to believe that the return value of OSICAT:LIST-DIRECTORY is
> predicated upon the return value of OSICAT:ABSOLUTE-PATHNAME and that
> it is the nuanced manner with which OSICAT:LIST-DIRECTORY interacts
> with OSICAT:ABSOLUTE-PATHNAME which is objectionable:

No, please. Don't assume that. See the docstring:

 Returns a fresh list of pathnames corresponding to all files
 within the directory named by the non-wild pathname designator
 PATHSPEC.
 If BARE-PATHNAMES is non-NIL only the files's bare pathnames are returned
 (with an empty directory component), otherwise the files' pathnames are
 merged with PATHSPEC.

Nothing about ABSOLUTE-PATHNAME there.

> Assuming current directory is "/home/bubba/quux/" and that the
> following is true:
>
> (equal (osicat:current-directory) *default-pathname-defaults*)
> ;=> t
>
> For (osicat:list-directory ".") I would like to see:
>
> (osicat:list-directory #P".")
> ;=> (#P"/home/bubba/quux/foo.txt")

This is not an unreasonable thing to want, but wrong for "." given
LIST-DIRECTORY's contract.

One of the key features of LIST-DIRECTORY is that if you feed it a
relative pathname, you get a list of relative pathnames back.

Changing that as a default is not acceptable.

You have to remember that we're talking about _lisp_ pathnames and
namestrings here, not POSIX ones -- so meaning of "." is
implementation dependent to a frightening degree.

/Practically/ at the end of the day, it mostly means same as POSIX .
but before the final syscall is done implementations are allowed to
parse the namestring "." in myriad different ways, as long as it
unparses back to the same string.

It might be reasonable for ABSOLUTE-PATHNAME to treat "." and ".."
specially. Not sure -- but I'm quite hesitant to do that and rather
leave the details to implementation's MERGE-PATHNAMES logic.

(In case of SBCL, I think it should treat those a bit more specially
than it does right now.)

To get what you want, you should do:

(osicat:list-directory (osicat:absolute-pathname *default-pathname-defaults*))

or -- somewhat less portable, but shorter:

(osicat:list-directory (osicat:absolute-pathname ""))

> To have surety that Osicat resolves the pathname designator "."
> consistently at all levels of its API and does so in a maner most
> consistent with CL handling of pathnames w/ specific regards to
> *default-pathname-defaults*.

No such guarantee, sorry.

What's portable about LIST-DIRECTORY is the way it gets the contents
of a directory: different implementations are annoyingly different
when it comes to constructing a wild pathname for DIRECTORY that gets
all files and subdirectories. With LIST-DIRECTORY you know what you
get, everywhere.

What's unportable about LIST-DIRECTORY is the canonicalization done by
MERGE-PATHNAMES of the host Lisp.

>> The Osicat API is not a POSIX API. It tries to find a place to stand
>> among the concepts shared by modern OSes and be a nice Lispy extension
>> to things in the standard.
>>
>
> Which standard, POSIX or ANSI-CL?

ANSI CL.

Cheers,

 -- Nikodemus