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

Fri Aug 12 19:36:23 UTC 2011

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\