I initially neglected to send this register an account w/ osicat-devel and mailed the following exchange to Nikodemus directly with the subject line: "osicat:list-directory vs. cl-fad:list-directory"
No doubt Nikodemus has plenty on his plate right now as it is and needn't be solely responsible for fielding this verobisty :)
I should have taken the time to register an osicat-devel account. Having done so I am now forwarding a transcript of my previous exchange.
-------------- On 12 August 2011 19:46, MON KEY wrote: I noticed today that on SBCL these return differently:
(cl-fad:list-directory ".") (osicat:list-directory ".") (cl-fad:list-directory "..") (osicat:list-directory "..")
Assuming this is a bug, then i'm pretty sure its origin is around the reliance on osicat:with-directory-iterator.
osicat:call-with-directory-iterator binds *d-p-d* to the value of the dir var before setting cwd in the protected form of its unwind-protect.
Further up in osicat:call-with-directory-iterator there is a merge with *d-p-d* via:
(osicat:absolute-pathname <PATHSPEC>)
When the PATHSPEC arg to osicat:list-directory is a dotted namestring e.g. "." or ".." the merge with *d-p-d* in osicat:call-with-directory-iterator will yield the equivalent of:
(merge-pathnames "." *default-pathname-defaults*)
such that for the duration of each #'one-iter *d-p-d* gets dynamically funky bound.
--------------
On Fri, Aug 12, 2011 at 1:07 PM, Nikodemus Siivola wrote:
The docstrings for many of the osicat functions mirror cl-fad's, so I am ssuming this is a bug, then i'm pretty sure its origin is around
Well, Osicat predates CL-FAD by a year or so, so not really.
A quick look at results from Osicat looks like just what I would expect -- what exactly is the difference you think is a bug?
Possibly you're looking for :bare-pathnames t?
---------------
On 12 August 2011 19:46, MON KEY wrote:
The docstrings for many of the osicat functions mirror cl-fad's, so I am assuming this is a bug, then i'm pretty sure its origin is around
Well, Osicat predates CL-FAD by a year or so, so not really.
Would you not agree that they are curiosly similar?
Possibly you're looking for :bare-pathnames t?
No, I didn't find :bare-pathnames t necessarily applicable w/r/t dotted-namestrings, and neither of the respcective below pairs do what I would expect:
(osicat:list-directory ".") (osicat:list-directory "." :bare-pathnames t)
(osicat:list-directory "..") (osicat:list-directory ".." :bare-pathnames t)
Note however, that these forms do retrun what i would expect:
(osicat:list-directory "./") (osicat:list-directory "." :bare-pathnames t)
(osicat:list-directory "../") (osicat:list-directory "../" :bare-pathnames t)
When a namestring is given as a dotted-namestring and a trailing #/ (solidus) is _not_ present, I would expect Osicat to resolve dotted-namestrings their cl:truename before executing the inspection PATHSPEC in the iterations.
When a namestring is given as a dotted-namestring and a trailing #/ (solidus) _is_ present I would expect Osicat to _not_ resolve the dotted-namestrings.
A quick look at results from Osicat looks like just what I would expect -- what exactly is the difference you think is a bug?
Following evaulated from SBCL "1.0.47.1":
*default-pathname-defaults* ;=> #P"/home/me/long-path/here/subdir/sub-subdir/"
(cl:pathname-type #P".") ;=> NIL
(cl:pathname-name #P".") ;=> "."
(cl:pathname-name "..") ;=> "."
(cl:pathname-name "..") ;=> "."
(cl:pathname-name "../") => NIL
(cl:pathname-name "./") => NIL
(cl:pathname-type ".") ;=> NIL
(cl:pathname-type "..") ;=> ""
(cl:pathname-type "./") ;=> NIL
(cl:pathname-type "../") ;=> NIL
(cl:pathname-directory ".") ;=> NIL
(cl:pathname-directory "..") ;=> NIL
(pathname-directory "./") ;=> (:RELATIVE ".")
(pathname-directory "../") ;=> (:RELATIVE :UP)
(cl:truename ".") ;=> #P"/home/me/long-path/here/subdir/sub-subdir/"
(cl:truename "..") ;=> #p"/home/sp/hg-repos/cl-repo-hg/cl-mon-code/"
(cl:truename "./") ;=> #P"/home/me/long-path/here/subdir/sub-subdir/"
(cl:truename "../") ;=> #P"/home/me/long-path/here/subdir/"
(cl:probe-file ".") ;=> #P"/home/me/long-path/here/subdir/sub-subdir/"
(cl:probe-file "..") ;=> #P"/home/me/long-path/here/subdir/"
(directory ".") ;=> (#P"/home/me/long-path/here/subdir/sub-subdir/")
(directory "..") ;=> (#P"/home/me/long-path/here/subdir/")
(osicat:absolute-pathname ".") ;=> #P"/home/me/long-path/here/subdir/sub-subdir/."
(osicat:absolute-pathname "..") ;=> #P"/home/me/long-path/here/subdir/sub-subdir/.."
(osicat:file-kind ".") ;=> :DIRECTORY
(osicat:file-kind "..") ;=> :DIRECTORY
(osicat:file-kind (osicat:absolute-pathname "..")) ;=> :DIRECTORY
(osicat:file-kind (osicat:absolute-pathname ".")) ;=> :DIRECTORY
(osicat:directory-pathname-p ".") ;=> NIL
(osicat:directory-pathname-p "..") ;=> NIL
(osicat:pathname-as-directory ".") ;=> #P"./"
(osicat:pathname-as-directory "..") ;=> #P"../"
(osicat:pathname-directory-pathname ".") ;=> #P""
(osicat:pathname-directory-pathname "..") ;=> #P""
Disregarding the following assertion from the README of Quicklisp's dist of Osicat as to the extent of its Posixness:
,---- | | Osicat is a lightweight operating system interface for Common Lisp | on Unix-platforms. It is not a POSIX-style API, but rather a simple | lispy accompaniment to the standard ANSI facilities. | `---- :SOURE osicat-20110619-git/README
It may be worth considering osicats behaviour w/r/t following from POSIX.1-2008 apropos dotted namestrings:
,---- | | 4.12 Pathname Resolution | {...} | | The special filename dot shall refer to the directory specified by | its predecessor. The special filename dot-dot shall refer to the | parent directory of its predecessor directory. As a special case, in | the root directory, dot-dot may refer to the root directory itself. | | The Open Group Base Specifications Issue 7 IEEE Std 1003.1-2008 | `---- :SOURCE (URL `http://pubs.opengroup.org/onlinepubs/9699919799/')
Following may also be applicable: (URL `http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#dot')
As mentioned on #lisp, I'm not interested in advocating that Osicat be changed if it isn't broken.
The reliable portablility offered by Osicat underscores my interest in it and I am currently in the process of converting the CL-FAD and SBCL specific routines use in my code to use Osicat instead :) As such, my concern/curiousity is to learn the rationale for its implementation so as to avoid unnecessary future surprises.
AFAICT Osicat absolute-pathname treats the dotted namestring as pathname-name whereas these: (osicat:file-kind "..") (osicat:file-kind ".") consider them to be pathname-directory.
So long as Osicat allows pathspec args to take occur as a namestring (as opposed to a #P"." or #P"..") then there remains a certain ambiguity as to what type of pathname component the user intended the dotted-namestring to resolve to.
To the extent with which the following behave similiarly: (osicat:list-directory ".") shell> ls . (osicat:list-directory ".") shell> ls ..
Osicats dotted-namestring seems sane.
However, barring `scandir` `readdir` where there isn't really a POSIX equivalent to osicat:mapdir, osicat:walk-directory, osicat:with-directory-iterator I would advocate that Osicat behave as SBLC does and resolve the dotted-namestring to its cl:truename.
-- /s_P\