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\
