Hi,
I think that there is a bug in akcl (615 an 619 beta versions) with
the function named merge-pathnames :
(merge-pathnames "lib/" "/usr/local")
should give : "/usr/local/lib"
but give : "lib/local"
Is it just me, my compiler (I tried with cc & gcc, with 615 & 619beta)
or a bug ?
Thanks,
Fabrice Popineau
------
--
e-mail: ········@ese-metz.fr
········@loria.fr
voice-mail: (+33) 87-74-99-38
surface-mail: Ecole Superieure d'Electricite
2 rue Edouard Belin
F-57078 Metz Cedex 3
FRANCE
In article <······················@prunel.ese-metz.fr> ········@prunel.ese-metz.fr (Fabrice Popineau) writes:
>I think that there is a bug in akcl (615 an 619 beta versions) with
>the function named merge-pathnames :
>
>(merge-pathnames "lib/" "/usr/local")
>should give : "/usr/local/lib"
>but give : "lib/local"
>
>Is it just me, my compiler (I tried with cc & gcc, with 615 & 619beta)
>or a bug ?
Namestring parsing is implementation-dependent, so the language can say
very little about what that form should return. From the above behavior,
it looks like (parse-namestring "lib/") returns a pathname whose directory
component is "lib" rather than (:RELATIVE "lib"), so when it is merged it
does a complete replacement of the directory portion rather than appending
the relative pathname.
If you want portable pathname behavior, you generally need to operate only
with pathname objects.
--
Barry Margolin
System Manager, Thinking Machines Corp.
······@think.com {uunet,harvard}!think!barmar
>>>>> "Barry" == Barry Margolin <······@think.com> writes:
In article <············@early-bird.think.com> ······@think.com (Barry Margolin) writes:
Barry> In article <······················@prunel.ese-metz.fr>
Barry> ········@prunel.ese-metz.fr (Fabrice Popineau) writes:
>> I think that there is a bug in akcl (615 an 619 beta versions)
>> with the function named merge-pathnames :
>>
>> (merge-pathnames "lib/" "/usr/local") should give :
>> "/usr/local/lib" but give : "lib/local"
>>
>> Is it just me, my compiler (I tried with cc & gcc, with 615 &
>> 619beta) or a bug ?
Barry> Namestring parsing is implementation-dependent, so the
Barry> language can say very little about what that form should
Barry> return. From the above behavior, it looks like
Barry> (parse-namestring "lib/") returns a pathname whose
Barry> directory component is "lib" rather than (:RELATIVE "lib"),
Barry> so when it is merged it does a complete replacement of the
Barry> directory portion rather than appending the relative
Barry> pathname.
Exactly. CLisp reports (:RELATIVE "lib"), and KCL reports "lib".
Barry> If you want portable pathname behavior, you generally need
Barry> to operate only with pathname objects.
Probably. But I was just trying to compile Garnet under KCL and it
chokes on these pathnames ...
Nevertheless, Garnet runs fine under CLisp.
Fabrice Popineau
-----
--
e-mail: ········@ese-metz.fr
········@loria.fr
voice-mail: (+33) 87-74-99-38
surface-mail: Ecole Superieure d'Electricite
2 rue Edouard Belin
F-57078 Metz Cedex 3
FRANCE
Fabrice Popineau <········@prunel.ese-metz.fr> states
> I think that there is a bug in akcl (615 an 619 beta versions) with
> the function named merge-pathnames :
>
> (merge-pathnames "lib/" "/usr/local")
> should give : "/usr/local/lib"
> but give : "lib/local"
"lib/" is equivalent to #S(Pathname :Directory "lib/" :Name nil :Type nil)
"/usr/local" ....... to #S(Pathname :Directory "/usr/" :Name "local" :Type nil)
so the MERGE-PATHNAMES function returns
#S(Pathname :Directory "lib/" :Name "local" :Type nil)
Barry Margolin <······@think.com> replies:
> Namestring parsing is implementation-dependent, so the language can say
> very little about what that form should return. From the above behavior,
> it looks like (parse-namestring "lib/") returns a pathname whose directory
> component is "lib" rather than (:RELATIVE "lib"), so when it is merged it
> does a complete replacement of the directory portion rather than appending
> the relative pathname.
>
> If you want portable pathname behavior, you generally need to operate only
> with pathname objects.
This doesn't catch the point.
MERGE-PATHNAMES is specified (CLtL2 p. 641) to fill in *unspecified*
components of the first pathname from the second pathname.
Since "lib/" specifies a directory component (relative to some other directory,
most probably the current working directory), the other pathname's directory
component is irrelevant.
You can't use MERGE-PATHNAMES to concatenate directories.
As a side note. Yes, namestring parsing is implementation-dependent, and
some Unix implementations interpret
"/usr/local" as #S(Pathname :Directory "/usr/" :Name "local" :Type nil)
and
"/usr/local/" as #S(Pathname :Directory "/usr/local/" :Name nil :Type nil).
Therefore it is wise to append a trailing slash if you mean a directory.
Bruno Haible
······@ma2s2.mathematik.uni-karlsruhe.de
In article <··········@nz12.rz.uni-karlsruhe.de> ······@ma2s2.mathematik.uni-karlsruhe.de writes:
>You can't use MERGE-PATHNAMES to concatenate directories.
Yes you can. From CLtL2 p.621:
Pathname merging treats a relative directory specially. ... If
(pathname-directory <pathname>) is a list whose CAR is :RELATIVE, and
(pathname-directory <defaults>) is a list, then the merged directory is the
value of
(append (pathname-directory <defaults>)
(cdr (pathname-directory <pathname>)))
except that if the resulting list contains a string or :WILD immediately
followed by :BACK, both of them are removed.
--
Barry Margolin
System Manager, Thinking Machines Corp.
······@think.com {uunet,harvard}!think!barmar
······@ma2s2.mathematik.uni-karlsruhe.de writes:
>Fabrice Popineau <········@prunel.ese-metz.fr> states
>> I think that there is a bug in akcl (615 an 619 beta versions) with
>> the function named merge-pathnames :
>>
>> (merge-pathnames "lib/" "/usr/local")
>> should give : "/usr/local/lib"
>> but give : "lib/local"
>Barry Margolin <······@think.com> replies:
>> Namestring parsing is implementation-dependent, so the language can say
>> very little about what that form should return. From the above behavior,
>> it looks like (parse-namestring "lib/") returns a pathname whose directory
>> component is "lib" rather than (:RELATIVE "lib"), so when it is merged it
>> does a complete replacement of the directory portion rather than appending
>> the relative pathname.
>>
>> If you want portable pathname behavior, you generally need to operate only
>> with pathname objects.
You also have to wait for all implementations to "catch up" with the
latest definition of CL.
>You can't use MERGE-PATHNAMES to concatenate directories.
You can in some implementations.
Unfortunately, right now it often works better to use strings rather
than pathnames, if you know the OS.
>Therefore it is wise to append a trailing slash if you mean a directory.
That's worked pretty well for me so far, at least.
-- jeff
On parcftp.xerox.com, in the file /pub/pcl/September-16-92-Systems.tar.Z,
in the file ./system.lisp (inside the tar file), there is code that
provides (shadowed) definitions of pathname functions including a
definition of merge pathnames that merges directories. It works in
AKCL, Lucid, and several other lisps.
Send email to ····@chestnut.com if you would like me to send you the
relevant portion of that file.
Richard Harris