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\