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

[MON KEY]

On Thu, Aug 18, 2011 at 2:47 AM, Nikodemus Siivola
<nikodemus at random-state.net> wrote:
> On 17 August 2011 21:00, MON KEY <monkey at sandpframing.com> wrote:
>
>> Again, I would prefer that (osicat:list-directory ".") not return a
>> value that is CL:EQUAL (osicat:list-directory "./").
>
> I honestly didn't understand /what/ you were finding objectionable
> before. So we're making progress here...

Great! I apologize if my previous communication was opaque.

>
> However, I disagree with this: treating "." and "./" identically is
> consistent with the way other directory name designators are dealt

I'm not clear on this. What is meant by:

"is consistent with the way other directory name designators are dealt
 with"

Is the referenced consistency w/r/t Osicat's dealings or CL's
dealings?

> with, and has more to do with the CL pathname logic (and braindamage)
> than with POSIX.
>

Maybe, but these also seem braindamaged:

 (osicat:absolute-pathname ".")
 ;=> #P"/home/bubba/quux/."

 (osicat:absolute-pathname "..")
 ;=> #P"/home/bubba/quux/.."

Whereas the equivalent of SBCL's CL pathname logic does not:

(truename (make-pathname :directory (pathname-directory ".")
                         :defaults *default-pathname-defaults*))
;=> #P"/home/bubba/quux/"

(truename (make-pathname :directory '(:RELATIVE :UP)
                         :defaults *default-pathname-defaults*))
;=> #P"/home/bubba/"

> Two questions:
>
> 1. Assuming current directory contains a single file "foo.txt", what
> would you like (osicat:list-directory ".") and (osicat:list-directory
> "./") to return?

I will answer your question with the proviso that I am currently given
to believe that the return value of OSICAT:LIST-DIRECTORY is
predicated upon the return value of OSICAT:ABSOLUTE-PATHNAME and that
it is the nuanced manner with which OSICAT:LIST-DIRECTORY interacts
with OSICAT:ABSOLUTE-PATHNAME which is objectionable:

Assuming current directory is "/home/bubba/quux/" and that the
following is true:

(equal (osicat:current-directory) *default-pathname-defaults*)
;=> t

For (osicat:list-directory ".") I would like to see:

(osicat:list-directory #P".")
;=> (#P"/home/bubba/quux/foo.txt")

I find this to be more in keeping with the following equivalent
invocation of COMMON-LISP:DIRECTORY, e.g.:

(directory (make-pathname :name :wild
                          :type :wild
                          :defaults (osicat:current-directory)))
;=> (#P"/home/bubba/quux/foo.txt")

Likewise, for (osicat:list-directory #P"./") I would like to see:
(osicat:list-directory #P"./")
;=> (#P"./foo.txt")

IOW, when the user expliclitly provides the trailing #\/ (solidus)
then return a list of relative pathnames, else return a list of
pathnames fully resolved to current directory.

>
> 2. What's the use-case?
>
To have surety that Osicat resolves the pathname designator "."
consistently at all levels of its API and does so in a maner most
consistent with CL handling of pathnames w/ specific regards to
*default-pathname-defaults*.

In my mind, if Osicat allows "." as a designator for a pathname,
and if "."  _always_ resolves to the directory that is current
(whether value of "current directory" is OSICAT:CURRENT-DIRECTORY
or *DEFAULT-PATHNAME-DEFAULTS*), then its return value should be
treated equivalently to CL's *default-pathname-defaults* e.g. from
the Spec for *d-p-d*:

 ,----
 | a pathname, used as the default whenever a function needs a default
 | pathname and one is not supplied.
 `----

  The general use case is therefor to have "." and ".." be fully
  resolved to an absolute pathname.

  And more generally that "." returned as an absolute pathname in the
  same manner as getcwd(3).

>
> The Osicat API is not a POSIX API. It tries to find a place to stand
> among the concepts shared by modern OSes and be a nice Lispy extension
> to things in the standard.
>

Which standard, POSIX or ANSI-CL?

Thanks again for taking the time to answer my questions.