On Fri, 2011-08-12 at 15:36 -0400, MON KEY wrote:
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.
This is the intended behavior, not a bug
[...]
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.
[...]
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
The README will probably need to be corrected, then
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.
POSIX file-systems have no notion of name and type, and syntax-wise a file and a directory are the same, so ".." is the same thing as "../"