[pg-cvs] osicat dotted-namestrings and absolute-pathname interaction around directory iterators
MON KEY
monkey at sandpframing.com
Wed Aug 17 17:48:51 UTC 2011
On Sat, Aug 13, 2011 at 9:15 AM, Nikodemus Siivola
<nikodemus at random-state.net> wrote:
> On 12 August 2011 22:36, MON KEY <monkey at sandpframing.com> wrote:
>
> I apologize for excising most of your post, but before getting into
> whys and hows, I'd like to understand the _what_.
>
To be clear when i am refering to dotted-pathnames and/or
dotted-namestrings I am referecing the following objects:
"." ; An unresolved CL:NAMESTRING with CL:PATHNAME-NAME "."
".." ; An unresolved CL:NAMESTRING with CL:PATHNAME-NAME "." and
CL:PATHNAME-TYPE ""
#P"." ; A CL:PATHNAME-NAME with CL:PATHNAME-NAME "."
#P".." ; A CL:PATHNAME-NAME with CL:PATHNAME-NAME "." and CL:PATHNAME-TYPE ""
When i am refering to relative-dotted-pathnames and/or
relative-dotted-namestrings I am referecing the following objects:
"./" ; An unresolved CL:NAMESTRING with CL:PATHNAME-DIRECTORY
(:relative ".")
"../" ; An unresolved CL:NAMESTRING with CL:PATHNAME-DIRECTORY
(:relative :up)
#P"./" ; An unresolved CL:PATHNAME with CL:PATHNAME-DIRECTORY
(:relative ".")
#P"../" ; An unresolved CL:PATHNAME with CL:PATHNAME-DIRECTORY
(:relative :up)
>
> I'm having trouble following your argument since for me:
>
> (equal (osicat:list-directory ".") (osicat:list-directory "./")) => T
Yes, it does for me too.
Can you acknowledge if on your SBCL system(s) the pathnames returned of the
above OSICAT:LIST-DIRECTORY forms are truncated relatively?
Can you acknowledge if on your SBCL system(s) when given a
dotted-namestring as argument to OSICAT:LIST-DIRECTORY the return
value is a list of pathnames with the directory component forms are
truncated as relative pathnames for the pathnames contained of such
lists?
And if so, can you acknowledge whether you understand that the
truncation as relative pathnames is part of what I'm finding
problematic?
And if so, can you acknowledge whether you understand that I am
asserting that there is a problem b/c SBCL does not consider
dotted-pathnames without trailing #\/ (solidus) to be representative
of a CL:PATHNAME-DIRECTORY? IOW can you acknowledge that SBCL does
not consider dotted-namestring/dotted-pathnames to be CL:EQUAL with a
dotted-namestring/dotted-pathnames with a trailing #\/ (solidus):
CL-USER> (equal (pathname-directory #P".")
(pathname-directory #P"./"))
;=> NIL
CL-USER> (equal (pathname-directory (truename #P"."))
(pathname-directory (truename #P"./")))
;=> T
CL-USER> (equal (pathname-directory #P"..")
(pathname-directory #P"../"))
;=> NIL
CL-USER> (equal (pathname-directory (truename #P".."))
(pathname-directory (truename #P"../")))
;=> T
Again, I would prefer that (osicat:list-directory ".") not return a
value that is CL:EQUAL (osicat:absolute-pathname "./").
My rationale for this preference is predicated on the return value of
the following forms, which on my current SBCL these are not CL:EQUAL:
CL-USER> (equal (osicat:absolute-pathname #P".")
(osicat:absolute-pathname #P"./"))
;=> NIL
CL-USER> (equal (osicat:absolute-pathname #P"..")
(osicat:absolute-pathname #P"../"))
;=> NIL
>
> . However, I did just discover that unexpectedly
>
> (equal (osicat:list-directory "..") (osicat:list-directory "../")) => NIL
>
Yes, I think this example begins to approach the problem/issue.
> but the proximate cause of this appears to be an SBCL's failure to
> normalize (:RELATIVE "..") to (:RELATIVE :UP), which doesn't seem
> right at all and violates print/read consistency requirements:
>
Perhaps SBCL has funky interpretation of the spec. my interpretation
is certainly less qualified than yours in this regard :)
However, regardless of whether SBCLs normalization is the locus of the
problem the normalization of dotted pathnames is none the less made
manifest with OSICAT:ABSOLUTE-PATHNAME.
I find this problematic because OSICAT:ABSOLUTE-PATHNAME is often
topmost in the call-chain of Osicat's directory
walking/mapping/listing procedures.
Can you acknowledge whether on your SBCL system(s) you get similar
return values for the following forms:
CL-USER> (pathname-directory #P".")
;=> NIL
CL-USER> (pathname-name #P".")
;=> "."
CL-USER> (pathname-type #P".")
;=> NIL
CL-USER> (pathname-directory #P"./")
;=> (:RELATIVE ".")
CL-USER> (pathname-name #P"./")
;=> NIL
CL-USER> (pathname-type #P"./")
;=> NIL
CL-USER> (equal (pathname-name #P".")
(pathname-name #P"./"))
;=> NIL
CL-USER> (pathname-directory #P"..")
;=> NIL
CL-USER> (pathname-name #P"..")
;=> "."
CL-USER> (pathname-type #P"..")
;=> ""
CL-USER> (pathname-directory #P"../")
;=> (:RELATIVE :UP)
CL-USER> (pathname-name #P"../")
;=> NIL
CL-USER> (pathname-type #P"../")
;=> NIL
CL-USER> (equal (pathname-name #P"..")
(pathname-name #P"../"))
;=> NIL
CL-USER> (equal (pathname-type #P"..")
(pathname-type #P"../"))
;=> NIL
If so, can you acknowledge whether you understand that I find the
following return values problematic w/r/t OSICAT:ABSOLUTE-PATHNAME b/c
it resolves dotted-namestring/dotted-pathnames differently than it
resolves relative-dotted-pathnames/relative-dotted-namestrings?
CL-USER> (osicat:absolute-pathname #P".")
;=> #P"/home/me/long-path/here/subdir/sub-subdir/."
CL-USER> (pathname-name (osicat:absolute-pathname #P"."))
;=> "."
CL-USER> (pathname-type (osicat:absolute-pathname #P"."))
=> NIL
CL-USER> (osicat:absolute-pathname #P"./")
;=> #P"/home/me/long-path/here/subdir/sub-subdir/./"
CL-USER> (pathname-name (osicat:absolute-pathname #P"./"))
;=> NIL
CL-USER> (pathname-type (osicat:absolute-pathname #P"./"))
;=> NIL
CL-USER> (equal (osicat:absolute-pathname #P"./")
(osicat:absolute-pathname #P"."))
;=> NIL
CL-USER> (osicat:absolute-pathname #P"..")
;=> #P"/home/me/long-path/here/subdir/sub-subdir/.."
CL-USER> (pathname-name (osicat:absolute-pathname #P".."))
;=> "."
CL-USER> (pathname-type (osicat:absolute-pathname #P".."))
;=> ""
CL-USER> (osicat:absolute-pathname #P"../")
;=> #P"/home/me/long-path/here/subdir/sub-subdir/../"
CL-USER> (pathname-name (osicat:absolute-pathname #P"../"))
;=> NIL
CL-USER> (pathname-type (osicat:absolute-pathname #P"../"))
;=> NIL
CL-USER> (osicat:absolute-pathname #P"../")
;=> #P"/home/me/long-path/here/subdir/sub-subdir/../"
CL-USER> (equal (pathname-name (osicat:absolute-pathname #P".."))
(pathname-name (osicat:absolute-pathname #P"../")))
;=> NIL
And if so, can you acknowledge whether you understand that I find this
problematic b/c where OSICAT:ABSOLUTE-PATHNAME's is top-most in a call
chain if/when it resolves relative-dotted-pathnames and/or
relative-dotted-namestrings differently than dotted-namestring and/or
dotted-pathnames on SBCL the return value to the calling function
causes unecessary inconsistencies with the Osicat directory
listing/mapping/walking functions and that such inconsistencies may in
turn present inconsistencies with the SBCLs interpretation of the
Common Lisp "API":
Such inconsistencies can be illustrated by return value of following:
(osicat:list-directory (osicat:absolute-pathname #P"."))
(osicat:list-directory (osicat:absolute-pathname #P".."))
CL-USER> (let* ((dot-ls
(osicat:list-directory (osicat:absolute-pathname #P".")))
(dot-ls-map
(map 'list #'osicat:file-exists-p dot-ls)))
(equal dot-ls dot-ls-map))
;=> NIL
CL-USER> (let* ((dot-dot-ls
(osicat:list-directory (osicat:absolute-pathname #P".")))
(dot-dot-ls-map
(map 'list #'osicat:file-exists-p dot-dot-ls)))
(equal dot-dot-ls dot-dot-ls-map))
;=> NIL
CL-USER> (equal (directory (osicat:absolute-pathname #P"."))
(directory (osicat:absolute-pathname #P"./")))
=> T
CL-USER> (equal (directory (osicat:absolute-pathname #P"../"))
(directory (osicat:absolute-pathname #P"..")))
=> T
>
> While "./" gets (:RELATIVE ".") which seems a bit odd, it is not AFAIK
> strictly speaking wrong.
>
This seems reasonable... In any event I've incorporated a rationale
into my understandting of SBCL's interpretation of the CL spec :)
What return value were you expecting, maybe Clisp's (:relative) instead?
> If you're objecting to (:relative "..") I concur.
Yes. Maybe.
I object to the use of (pathname-directory #P"\\../")
Is there some specific reason why you prepended "\\" to the
relative-dotted-namestrings?
Is there some Windows specific rationale for this?
IIRC Windows should be capable of resolving #P"../"
This being said, (truename #P"\\../") resolves correctly relative to
*default-pathname-defaults*.
CL-USER> (truename #P"\\../")
;=> #P"/home/me/long-path/here/subdir/"
Whereas IMHO this return value is (from a CL perspective) wrong:
CL-USER> (osicat:absolute-pathname #P"\\../")
;=> #P"/home/me/long-path/here/subdir/sub-subdir/../"
One must then truenamize the result to get what I would consider a
reasonably sane CL pathanme:
CL-USER> (truename (osicat:absolute-pathname #P"\\../"))
;=> #P"/home/me/long-path/here/subdir/"
I would however acknowledge that from a posix perspective the
following does appear to return sanely:
CL-USER> (let ((current (osicat:current-directory)))
(unwind-protect
(equal (list T T)
(list (equal current
#P"/home/me/long-path/here/subdir/sub-subdir/")
(equal (progn
(osicat-posix:chdir
(osicat:absolute-pathname #P"\\../"))
(osicat:current-directory))
#P"/home/me/long-path/here/subdir/")))
(osicat-posix:chdir current)))
;=> T
>
> If you're objecting to something else, please clarify.
>
I hope i've clarified _something_ :)
--
/s_P\
More information about the osicat-devel
mailing list