On Thu, Aug 18, 2011 at 2:47 AM, Nikodemus Siivola nikodemus@random-state.net wrote:
On 17 August 2011 21:00, MON KEY monkey@sandpframing.com wrote:
Again, I would prefer that (osicat:list-directory ".") not return a value that is CL:EQUAL (osicat:list-directory "./").
I honestly didn't understand /what/ you were finding objectionable before. So we're making progress here...
Great! I apologize if my previous communication was opaque.
However, I disagree with this: treating "." and "./" identically is consistent with the way other directory name designators are dealt
I'm not clear on this. What is meant by:
"is consistent with the way other directory name designators are dealt with"
Is the referenced consistency w/r/t Osicat's dealings or CL's dealings?
with, and has more to do with the CL pathname logic (and braindamage) than with POSIX.
Maybe, but these also seem braindamaged:
(osicat:absolute-pathname ".") ;=> #P"/home/bubba/quux/."
(osicat:absolute-pathname "..") ;=> #P"/home/bubba/quux/.."
Whereas the equivalent of SBCL's CL pathname logic does not:
(truename (make-pathname :directory (pathname-directory ".") :defaults *default-pathname-defaults*)) ;=> #P"/home/bubba/quux/"
(truename (make-pathname :directory '(:RELATIVE :UP) :defaults *default-pathname-defaults*)) ;=> #P"/home/bubba/"
Two questions:
- 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:
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")
I find this to be more in keeping with the following equivalent invocation of COMMON-LISP:DIRECTORY, e.g.:
(directory (make-pathname :name :wild :type :wild :defaults (osicat:current-directory))) ;=> (#P"/home/bubba/quux/foo.txt")
Likewise, for (osicat:list-directory #P"./") I would like to see: (osicat:list-directory #P"./") ;=> (#P"./foo.txt")
IOW, when the user expliclitly provides the trailing #/ (solidus) then return a list of relative pathnames, else return a list of pathnames fully resolved to current directory.
- What's the use-case?
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*.
In my mind, if Osicat allows "." as a designator for a pathname, and if "." _always_ resolves to the directory that is current (whether value of "current directory" is OSICAT:CURRENT-DIRECTORY or *DEFAULT-PATHNAME-DEFAULTS*), then its return value should be treated equivalently to CL's *default-pathname-defaults* e.g. from the Spec for *d-p-d*:
,---- | a pathname, used as the default whenever a function needs a default | pathname and one is not supplied. `----
The general use case is therefor to have "." and ".." be fully resolved to an absolute pathname.
And more generally that "." returned as an absolute pathname in the same manner as getcwd(3).
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?
Thanks again for taking the time to answer my questions.