Daniel Barlow wrote:
>
> james anderson <[EMAIL PROTECTED]> writes:
>
> > is there some logic behind this.? does proper practice require that
> > that all arguments are upcased before attempting logical pathname
> > operations? (note above that an attempt to provide both upper- and
> > lowercase patterns was canonicalized away.)
>
> According to ANSI, lowercase characters in a logical pathname
> namestring are translated to uppercase. See CLHS 19.3.1.1.7
i would have understood that, together with the discursive description in cltl2, to
imply that case normalization would have to occur on components as well as namestrings.
otherwise make-pathname fails to make logical pathnames.
i won't presume that any more and instead always supply upper case for any distinct
explicit components.
>
> I'd always believed there's a corresponding restriction on the
> contents of LPN components such that a LPN with lowercase in any of
> its components has undefined behaviour, but I can't find the reference
> for that one today, nor any reference to whether MAKE-PATHNAME
> should do case folding or not. Although you could read 19.3.1.1.8
> that way, I suppose.
yes, i would have. otherwise it is not making a logical pathname when it should.
>
> Pathnames are, in my experience, one of the least well-defined parts
> of the standard, and LPNs vie with COMPILE-FILE-PATHNAME for the
> darkest corner of this grey area.
>
i try to take advantage of their implementation independance.
> As a user, I (a) try to avoid LPNs anyway, (b) when I must use them,
> use uppercase exclusively. As an implementor, my vote is for having
> MAKE-PATHNAME fold case.
>
> In SBCL -
> * (logical-pathname "CL-LIBRARY:CODE;BASE;PARAMETERS.bin")
> #.(CL:LOGICAL-PATHNAME "CL-LIBRARY:CODE;BASE;PARAMETERS.BIN")
> * (make-pathname :host "CL-LIBRARY" :name "foo" :type "bar")
> #.(CL:LOGICAL-PATHNAME "CL-LIBRARY:FOO.BAR")
which is why when i was building for sbcl, the binaries ended up where they were
supposed to be.
thanks.
...
