merge-pathnames
Andy Brezing
Hi
Some question to a the CL implementation on a UNIX platform of
'merge-pathnames'. I would like to change the pathname-type of a
pathname by using 'merge-pathnames'.
Which version of 'merge-pathnames' might be wrong ?
Version 1 (CLISP)
> (merge-pathnames ".kll" "a/d/f/g/LISPIO.FASL.0")
#"a/d/f/g/LISPIO.FASL.kll"
or Version 2 (Harlequin LW)
> (merge-pathnames ".kll" "a/d/f/g/LISPIO.FASL.0")
#"a/d/f/g/.kll"
If version 1 is 'CL-standard' it would be fine :-).
Thanks in advance.
Cheers
Andy
**** E-MAIL: bre...@gia.rwth-aachen.de
Erik Naggum
* Andy Brezing
| Some question to a the CL implementation on a UNIX platform of
| 'merge-pathnames'. I would like to change the pathname-type of a pathname
| by using 'merge-pathnames'.
well, if you insist on MERGE-PATHNAMES:
(merge-pathnames (make-pathname :type "kll") <default>)
but I would recommend
(make-pathname :type "kll" :defaults <default>)
| Which version of 'merge-pathnames' might be wrong?
both may be correct. please note that just trying a Lisp implementation
without knowing what to expect is not a very good way to understand what
the language does. in particular, CLISP implements only what the authors
agree to, without any form of commitment to conformance.
note that MERGE-PATHNAMES is not specified to take strings as arguments,
but "pathname designators". strings are processed by PARSE-NAMESTRING to
become pathnames. this means that you will find out what you get by
evaluating
(describe (parse-namestring ".kll"))
in the available Common Lisp environments. (ordinarily, it would be
enough to do (describe #P".kll"), but CLISP doesn't seem to think #P is
worth implementing, either, at least not in the latest version I could
get to build here.)
#:Erik
--
Abort, Retry, or Upgrade?
Sunil Mishra
In article <353B5E...@gia.rwth-aachen.de> Andy Brezing <bre...@gia.rwth-aachen.de> writes:
Hi
Some question to a the CL implementation on a UNIX platform of
'merge-pathnames'. I would like to change the pathname-type of a
pathname by using 'merge-pathnames'.
Instead of merge-pathnames, try make-pathname.
CL-USER 17 > (make-pathname :type "wfasl" :defaults "/usr/local/lisp/foo.lisp")
#P"/usr/local/lisp/foo.wfasl"
Which version of 'merge-pathnames' might be wrong ?
Version 1 (CLISP)
> (merge-pathnames ".kll" "a/d/f/g/LISPIO.FASL.0")
#"a/d/f/g/LISPIO.FASL.kll"
or Version 2 (Harlequin LW)
> (merge-pathnames ".kll" "a/d/f/g/LISPIO.FASL.0")
#"a/d/f/g/.kll"
If version 1 is 'CL-standard' it would be fine :-).
I think this is an issue of UNIX filesystem conventions and implementation
dependent features. In unix, it is quite common to find a file beginning
with a ".", such as ".lispworks". Given a file name beginning with a
period, lispworks interprets the entire name as the name of the file,
rather than the type. If on the other hand, you had:
CL-USER 18 > (merge-pathnames (make-pathname :type "wfasl")
"/usr/local/lisp/foo.lisp")
#P"/usr/local/lisp/foo.wfasl"
All these examples are on lispworks 3.2.2 on unix.
Sunil
Kent M Pitman
Andy Brezing <bre...@gia.rwth-aachen.de> writes:
> Some question to a the CL implementation on a UNIX platform of
> 'merge-pathnames'. I would like to change the pathname-type of a
> pathname by using 'merge-pathnames'.
>
> Which version of 'merge-pathnames' might be wrong ?
>
> Version 1 (CLISP)
>
> > (merge-pathnames ".kll" "a/d/f/g/LISPIO.FASL.0")
> #"a/d/f/g/LISPIO.FASL.kll"
>
>
> or Version 2 (Harlequin LW)
>
> > (merge-pathnames ".kll" "a/d/f/g/LISPIO.FASL.0")
> #"a/d/f/g/.kll"
>
> If version 1 is 'CL-standard' it would be fine :-).
The issue here is not MERGE-PATHNAMES, which is doubtless correct
in both implementations.
The issue is the mapping from strings to pathnames. You are confusing
yourself by assuming that the mapping of ".kll" is obvious.
The standard takes no position on this. Each implementation must
define a mapping between the implementation and the host file system.
For many hardware impleemtnations, there was only one lisp vendor and
standardizing the meanings didn't make sense. Vendors need to
informally agree, probably, and maybe future standards work should
address this. But so it goes. Use MAKE-PATHNAME if you're in doubt.
Btw, the case you're looking at is peculiar because on Unix filenames
named .foo are magic. These are sometimes called "invisible" files
on Unix--they're the ones that you have to use the "-a" option in "ls"
to see. They are parsed by many implementations
(like Harlequin) as NAME="" TYPE="foo", so they have odd
merging behavior because names like ".bashrc" are complete filenames
that ought not be merged into. That is, many implementations want
(merge-pathnames ".login" "foo.lisp") => ".login"
which is desirable to many applications, so to do this they adjust
the parsing of ".login" to make sure it `fills' both the name and the
type with non-mergeable items (either NAME="" TYPE="login" or
NAME=".login" TYPE=:UNSPECIFIC would be the obvious two choices;
most implementations I know use the former). So if you're more careful,
you'll try:
(merge-pathnames (make-pathname :type "kll") "a/d/f/g/LISPIO.FASL.0")
=> #P"a/d/f/g/LISPIO.FASL.kll" ; <= Harlequin LispWorks 4.1
Thomas A. Russ
Andy Brezing <bre...@gia.rwth-aachen.de> writes:
>
> Hi
>
> Some question to a the CL implementation on a UNIX platform of
> 'merge-pathnames'. I would like to change the pathname-type of a
> pathname by using 'merge-pathnames'.
>
> Which version of 'merge-pathnames' might be wrong ?
I suspect that both are conforming implementations. The reason is that
the standard doesn't address how to parse a particular namestring into a
pathname. Essentially the parsing of a string into a pathname is
implementation defined.
> Version 1 (CLISP)
>
> > (merge-pathnames ".kll" "a/d/f/g/LISPIO.FASL.0")
> #"a/d/f/g/LISPIO.FASL.kll"
CLISP apparently parses ".kll" into
(make-pathname :name nil :type "kll")
> or Version 2 (Harlequin LW)
>
> > (merge-pathnames ".kll" "a/d/f/g/LISPIO.FASL.0")
> #"a/d/f/g/.kll"
Harlequin apparently parses ".kll" into
(make-pathname :name ".kll" :type nil)
> If version 1 is 'CL-standard' it would be fine :-).
If you want CL-standard, you should try
(merge-pathnames (make-pathname :type ".kll") "a/d/f/g/LISPIO.FASL.0")
Which should do what you want in a reasonably portable manner. For
maximum portability, you should also make the second argument a pathname
object, but I suspect that it is a value passed in from outside the
program. You may need to rely on appropriate parsing for it.
The only place you could potentially get in trouble is that if the
implmentation dependent parsing parsed "LISPIO.FASL.0" into
(make-pathname :name "LISPIO" :type "FASL" :version 0)
instead of
(make-pathname :name "LISPIO.FASL" :type "0")
.
>
> Thanks in advance.
>
> Cheers
>
> Andy
>
> **** E-MAIL: bre...@gia.rwth-aachen.de
--
Thomas A. Russ, USC/Information Sciences Institute t...@isi.edu
Bruno Haible
>> Version 1 (CLISP)
>>
>> > (merge-pathnames ".kll" "a/d/f/g/LISPIO.FASL.0")
>> #"a/d/f/g/LISPIO.FASL.kll"
>
> CLISP apparently parses ".kll" into
> (make-pathname :name nil :type "kll")
Yes, this is what CLISP currently does. But please don't rely on it:
CLISP is likely to be changed to parse ".kll" the same way as CMUCL
and Harlequin LW do.
Bruno
Bruno Haible
Erik Naggum <cle...@naggum.no> wrote:
>
> ordinarily, it would be
> enough to do (describe #P".kll"), but CLISP doesn't seem to think #P is
> worth implementing, either, at least not in the latest version I could
> get to build here.
CLISP implements #P since version 1997-05-03.
If you have problems building clisp on some particular platform, and
want these problems resolved, a constructive approach would be to submit
a report to <clisp...@clisp.cons.org>. This way the problems have a real
chance to be fixed.
Erik Naggum
* Bruno Haible
| CLISP implements #P since version 1997-05-03.
that's good.
| If you have problems building clisp on some particular platform, and want
| these problems resolved, a constructive approach would be to submit a
| report to <clisp...@clisp.cons.org>. This way the problems have a real
| chance to be fixed.
support for sun-sparc-sunos4.1.3 has obviously been scuttled to support a
myriad weird things in Linux. attempts to get support have failed. my
last attempt (three months ago) was to build on both my SPARCstation and
an Intel running Solaris 2.5. both failed with an _astonishing_ amount
of crud, most of it evidence of sloppy coding in that weird "D" language
of yours, which, to my untrained eyes, only appear to be a nasty way of
saying you don't like /* and */ in C. I don't like gratuitous changes
like that, so I am obviously just as free to ignore CLISP and warn people
against it as you are against the Common Lisp and C that other people
would like to use. I'm sorry, but I don't find _your_ unconstructive
approach to wasting my time worth it, especially when I can spend my time
so much more constructively elsewhere. maybe something to consider?
(BTW, something of the same nature has happened to GCL. I got my hands
on KCL back in 1987, but the C code was obviously written by someone who
had never seen anybody else's C code, just like yours, and although it
has now become GCL (via AKCL), it is still _incredibly_ obtuse and just
as buggy. I guess the morale is: if you want people to be benevolent to
you, at least don't start off by doing something boneheadedly different
just for the heck of it.)