On 22 August 2011 01:44, MON KEY monkey@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.
- 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