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

[Nikodemus Siivola]

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_.

> 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)

I'm having trouble following your argument since for me:

  (equal (osicat:list-directory ".") (osicat:list-directory "./")) => T

. However, I did just discover that unexpectedly

  (equal (osicat:list-directory "..") (osicat:list-directory "../")) => NIL

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:

CL-USER> (pathname-directory (pathname "\\../"))
(:RELATIVE "..")
CL-USER> (pathname "\\../")
#P"../"
CL-USER> (pathname-directory #p"../")
(:RELATIVE :UP)

While "./" gets (:RELATIVE ".") which seems a bit odd, it is not AFAIK
strictly speaking wrong.

If you're objecting to (:relative "..") I concur.

If you're objecting to something else, please clarify.

Cheers,

 -- nikodemus