On Sat, Aug 13, 2011 at 9:15 AM, Nikodemus Siivola nikodemus@random-state.net wrote:
On 12 August 2011 22:36, MON KEY monkey@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\