[pg-cvs] osicat dotted-namestrings and absolute-pathname interaction around directory iterators

[Stelian Ionescu]

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 "../"


-- 
Stelian Ionescu a.k.a. fe[nl]ix
Quidquid latine dictum sit, altum videtur.
http://common-lisp.net/project/iolib
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <https://mailman.common-lisp.net/pipermail/osicat-devel/attachments/20110813/0c15a91b/attachment.sig>