According to the HyperSpec entry for `parse-namestring', if the the
first argument ("thing") is a string and the second argument ("host") is
nil, and the
,----[ Function: PARSE-NAMESTRING ]
| "thing" is a syntactically valid logical pathname namestring containing
| an explicit host, then it is parsed as a logical pathname namestring.
`----
That suggests that with a logical host defined for, say, "home", the
following string should parse as a logical pathname:
"home:foo.lisp"
My implementation rejects it.
Consider a logical host definition as follows:
,----
| (let* ((to-wildcard-base
| (concatenate 'string (namestring (user-homedir-pathname))
| "**/*"))
| (to-wildcard-with-ext
| (concatenate 'string to-wildcard-base
| ".*.*")))
| (setf (logical-pathname-translations "home")
| `(("**;*" ,to-wildcard-base)
| (";**;*" ,to-wildcard-base)
| ("**;*.*.*" ,to-wildcard-with-ext)
| (";**;*.*.*" ,to-wildcard-with-ext))))
`----
Now take a look at this:
,----
| > (logical-pathname-translations "home")
| ((#S(LOGICAL-PATHNAME :HOST "HOME" :DEVICE :UNSPECIFIC
| :DIRECTORY (:ABSOLUTE :WILD-INFERIORS)
| :NAME :WILD :TYPE NIL :VERSION NIL)
| "/home/me/**/*")
| ((#S(LOGICAL-PATHNAME :HOST "HOME" :DEVICE :UNSPECIFIC
| :DIRECTORY (:RELATIVE :WILD-INFERIORS)
| :NAME :WILD :TYPE NIL :VERSION NIL)
| "/home/me/**/*")
| (#S(LOGICAL-PATHNAME :HOST "HOME" :DEVICE :UNSPECIFIC
| :DIRECTORY (:ABSOLUTE :WILD-INFERIORS)
| :NAME :WILD :TYPE :WILD :VERSION :WILD)
| "/home/me/**/*.*.*")
| (#S(LOGICAL-PATHNAME :HOST "HOME" :DEVICE :UNSPECIFIC
| :DIRECTORY (:RELATIVE :WILD-INFERIORS)
| :NAME :WILD :TYPE :WILD :VERSION :WILD)
| "/home/me/**/*.*.*"))
|
| > (logical-pathname "home:foo.lisp")
| #S(LOGICAL-PATHNAME :HOST "HOME" :DEVICE :UNSPECIFIC
| :DIRECTORY (:ABSOLUTE) :NAME "FOO"
| :TYPE "LISP" :VERSION NIL)
|
| > (parse-namestring "home:foo.lisp" "home")
| #S(LOGICAL-PATHNAME :HOST "HOME" :DEVICE :UNSPECIFIC
| :DIRECTORY (:ABSOLUTE) :NAME "FOO"
| :TYPE "LISP" :VERSION NIL)
| 13
|
| > (parse-namestring "home:foo.lisp")
| ; Evaluation aborted.
`----
The last one fails with the following error:
,----
| PARSE-NAMESTRING: syntax error in filename "home:foo.lisp"
| at position 4
`----
That is, CLISP� refuses to honor that string as a "syntactically valid
logical pathname namestring" when the "host" argument is nil.
Is this a bug in CLISP?
Footnotes:
� > (lisp-implementation-version)
"2.46 (2008-07-02) (built on reini [10.0.0.5])"
--
Steven E. Harris
"Steven E. Harris" <···@panix.com> writes:
> According to the HyperSpec entry for `parse-namestring', if the the
> first argument ("thing") is a string and the second argument ("host") is
> nil, and the
>
> ,----[ Function: PARSE-NAMESTRING ]
> | "thing" is a syntactically valid logical pathname namestring containing
> | an explicit host, then it is parsed as a logical pathname namestring.
> `----
>
> That suggests that with a logical host defined for, say, "home", the
> following string should parse as a logical pathname:
>
> "home:foo.lisp"
>
> My implementation rejects it.
>
> Consider a logical host definition as follows:
> [...]
> The last one fails with the following error:
>
> ,----
> | PARSE-NAMESTRING: syntax error in filename "home:foo.lisp"
> | at position 4
> `----
>
> That is, CLISP� refuses to honor that string as a "syntactically valid
> logical pathname namestring" when the "host" argument is nil.
"home" is not a logical host name. "HOME" is a logical host name.
("home" taken as a logical host name is some infame implementation
dependant monster).
I fail to see the point of using logical pathname if it is not to do
it in a manner that is strictly and portably standard conformant.
C/USER1[23]> (let* ((to-wildcard-base
(concatenate 'string (namestring (user-homedir-pathname))
"**/*"))
(to-wildcard-with-ext
(concatenate 'string to-wildcard-base
".*.*")))
(setf (logical-pathname-translations "HOME")
`(("**;*" ,to-wildcard-base)
(";**;*" ,to-wildcard-base)
("**;*.*.*" ,to-wildcard-with-ext)
(";**;*.*.*" ,to-wildcard-with-ext))))
((#P"HOME:**;*" "/home/pjb/**/*") (#P"HOME:;**;*" "/home/pjb/**/*")
(#P"HOME:**;*.*.*" "/home/pjb/**/*.*.*")
(#P"HOME:;**;*.*.*" "/home/pjb/**/*.*.*"))
C/USER1[24]> (logical-pathname-translations "HOME")
((#P"HOME:**;*" "/home/pjb/**/*") (#P"HOME:;**;*" "/home/pjb/**/*")
(#P"HOME:**;*.*.*" "/home/pjb/**/*.*.*")
(#P"HOME:;**;*.*.*" "/home/pjb/**/*.*.*"))
C/USER1[25]> (logical-pathname "HOME:FOO.LISP")
#P"HOME:FOO.LISP"
C/USER1[26]> (parse-namestring "HOME:FOO.LISP" "HOME")
#P"HOME:FOO.LISP" ;
13
C/USER1[27]> (parse-namestring "HOME:FOO.LISP")
#P"HOME:FOO.LISP" ;
13
C/USER1[28]> (translate-logical-pathname "HOME:FOO.LISP")
#P"/home/pjb/foo.lisp"
C/USER1[29]> (lisp-implementation-version)
"2.41 (2006-10-13) (built on thalassa.lan.informatimago.com [192.168.1.198])"
> Is this a bug in CLISP?
No.
--
__Pascal Bourguignon__ http://www.informatimago.com/
"This statement is false." In Lisp: (defun Q () (eq nil (Q)))
···@informatimago.com (Pascal J. Bourguignon) writes:
> "home" is not a logical host name. "HOME" is a logical host name.
> ("home" taken as a logical host name is some infame implementation
> dependant monster).
I tried your example, replacing lowercase "home" with the uppercase
"HOME", and got all the same results as my first attempt. For example,
(parse-namestring "HOME:FOO.LISP")
still fails with a syntax error at position 4. I don't think it's a
problem with my typing. Did I miss a distinction in your example other
than changing the case of the host and file name strings?
--
Steven E. Harris
"Steven E. Harris" <···@panix.com> writes:
> ···@informatimago.com (Pascal J. Bourguignon) writes:
>
>> "home" is not a logical host name. "HOME" is a logical host name.
>> ("home" taken as a logical host name is some infame implementation
>> dependant monster).
>
> I tried your example, replacing lowercase "home" with the uppercase
> "HOME", and got all the same results as my first attempt. For example,
>
> (parse-namestring "HOME:FOO.LISP")
>
> still fails with a syntax error at position 4. I don't think it's a
> problem with my typing. Did I miss a distinction in your example other
> than changing the case of the host and file name strings?
I tried it in 2.46, and it works the same, either with or without
-ansi (I usually work with -ansi, and sometimes it gives different
results than without).
--
__Pascal Bourguignon__ http://www.informatimago.com/
"Klingon function calls do not have "parameters" -- they have
"arguments" and they ALWAYS WIN THEM."
···@informatimago.com (Pascal J. Bourguignon) writes:
> I tried it in 2.46, and it works the same, either with or without
> -ansi (I usually work with -ansi, and sometimes it gives different
> results than without).
I tried it with "-ansi", and got the following:
,----
| [1]> (parse-namestring "home:foo.lisp")
| #P"HOME:FOO.LISP" ;
| 13
`----
It parsed it without complaining.
With this clue in hand, I found this explanation:
,----
| CLISP Implementation Notes, Section 19.5.3
| Function PARSE-NAMESTRING
| http://clisp.podval.org/impnotes/filename-misc.html#parsename
`----
One can enable the behavior I was seeking by setting the variable
CUSTOM:*PARSE-NAMESTRING-ANSI* to non-nil.
Thank you for pushing in the right direction.
--
Steven E. Harris
From: Richard M Kreuter
Subject: Re: parse-namestring and logical pathnames
Date:
Message-ID: <87hc81bi6k.fsf@progn.net>
···@informatimago.com (Pascal J. Bourguignon) writes:
> "home" is not a logical host name. "HOME" is a logical host name.
> ("home" taken as a logical host name is some infame implementation
> dependant monster).
Maybe, but there's no particularly good reason for implementations not
to recognize strings as host designators case-insensitively.
--
RmK
Richard M Kreuter <·······@progn.net> writes:
> ···@informatimago.com (Pascal J. Bourguignon) writes:
>
>> "home" is not a logical host name. "HOME" is a logical host name.
>> ("home" taken as a logical host name is some infame implementation
>> dependant monster).
>
> Maybe, but there's no particularly good reason for implementations not
> to recognize strings as host designators case-insensitively.
Well, ok. And indeed both clisp 2.41 and clisp 2.46 can
(translate-logical-pathname "home:foo.lisp")
to: #P"/home/pjb/foo.lisp" here. So Steven's problem may be
something else.
--
__Pascal Bourguignon__ http://www.informatimago.com/
"Klingon function calls do not have "parameters" -- they have
"arguments" and they ALWAYS WIN THEM."
* (Pascal J. Bourguignon) <··············@hubble.informatimago.com> :
Wrote on Sat, 27 Sep 2008 08:40:37 +0200:
|
| I fail to see the point of using logical pathname if it is not to do
| it in a manner that is strictly and portably standard conformant.
There may be NO WAY to do this; Especially if TRANSLATE-LOGICAL-PATHNAME
is required and you use uppercase in your logical pathname strings.
| C/USER1[23]> (let* ((to-wildcard-base
| (concatenate 'string (namestring (user-homedir-pathname))
| "**/*"))
| (to-wildcard-with-ext
| (concatenate 'string to-wildcard-base
| ".*.*")))
Aside: This sort of concatenating physical pathnames as strings is
implementation specific. To be portable you have to use
(let* ((to-wildcard-base
(merge-pathnames
(make-pathname :host nil :name :wild :type :wild :version :wild)
(user-homedir-pathname) nil))
(to-wildcard-with-ext
(merge-pathnames
(make-pathname :host nil :name :wild :type :wild :version :wild)
(user-homedir-pathname) nil)))
| (setf (logical-pathname-translations "HOME")
| `(("**;*" ,to-wildcard-base)
| (";**;*" ,to-wildcard-base)
| ("**;*.*.*" ,to-wildcard-with-ext)
<snip>
| C/USER1[27]> (parse-namestring "HOME:FOO.LISP")
| #P"HOME:FOO.LISP" ;
| 13
=> #P"HOME:FOO.LISP", 13
so far so good
| C/USER1[28]> (translate-logical-pathname "HOME:FOO.LISP")
| #P"/home/pjb/foo.lisp"
If you're after ~/foo.lisp you cannot use "HOME:FOO.LISP" to refer to
this file with allegro. You have to use "HOME:foo.lisp" as your logical
pathname.
* (translate-logical-pathname "HOME:FOO.LISP")
=> #P"/home/madhu/FOO.LISP"
* (lisp-implementation-version)
=> "8.1 [Linux (x86)] (Aug 9, 2008 1:00)"
This is not a bug in Allegro.
Function TRANSLATE-LOGICAL-PATHNAME
,----
| translate-logical-pathname might perform additional translations,
| typically to provide translation of file types to local naming
| conventions, to accomodate physical file systems with limited length
| names, or to deal with special character requirements such as
| translating hyphens to underscores or uppercase letters to
| lowercase. Any such additional translations are
| implementation-defined. Some implementations do no additional
| translations.
`----
So. if you think using uppercase is a necessary condition to ensure
portability (while ensuring it works!), you are mistaken :)
--
Madhu
PS: Is there some documented/undocumented way to modify t-l-p behaviour
in allegro?
* (Pascal J. Bourguignon) <··············@hubble.informatimago.com> :
Wrote on Sat, 27 Sep 2008 08:40:37 +0200:
|
| I fail to see the point of using logical pathname if it is not to do
| it in a manner that is strictly and portably standard conformant.
There may be NO WAY to do this; Especially if TRANSLATE-LOGICAL-PATHNAME
is required and you use uppercase in your logical pathname strings.
| C/USER1[23]> (let* ((to-wildcard-base
| (concatenate 'string (namestring (user-homedir-pathname))
| "**/*"))
| (to-wildcard-with-ext
| (concatenate 'string to-wildcard-base
| ".*.*")))
Aside: This sort of concatenating physical pathnames as strings is
implementation specific. To be portable you have to use.
(let* ((to-wildcard-base
(merge-pathnames
(make-pathname :host nil :name :wild :type nil :version nil
:directory '(:relative :wild-inferiors))
(user-homedir-pathname) nil))
(to-wildcard-with-ext
(merge-pathnames
(make-pathname :host nil :name :wild :type :wild :version :wild
:directory '(:relative :wild-inferiors))
(user-homedir-pathname) nil)))
[supersede fixes this above code to do what the OP intended]
| (setf (logical-pathname-translations "HOME")
| `(("**;*" ,to-wildcard-base)
| (";**;*" ,to-wildcard-base)
| ("**;*.*.*" ,to-wildcard-with-ext)
<snip>
| C/USER1[27]> (parse-namestring "HOME:FOO.LISP")
| #P"HOME:FOO.LISP" ;
| 13
=> #P"HOME:FOO.LISP", 13
so far so good
| C/USER1[28]> (translate-logical-pathname "HOME:FOO.LISP")
| #P"/home/pjb/foo.lisp"
If you're after ~/foo.lisp you cannot use "HOME:FOO.LISP" to refer to
this file with allegro. You have to use "HOME:foo.lisp" as your logical
pathname.
* (translate-logical-pathname "HOME:FOO.LISP")
=> #P"/home/madhu/FOO.LISP"
* (lisp-implementation-version)
=> "8.1 [Linux (x86)] (Aug 9, 2008 1:00)"
This is not a bug in Allegro.
Function TRANSLATE-LOGICAL-PATHNAME
,----
| translate-logical-pathname might perform additional translations,
| typically to provide translation of file types to local naming
| conventions, to accomodate physical file systems with limited length
| names, or to deal with special character requirements such as
| translating hyphens to underscores or uppercase letters to
| lowercase. Any such additional translations are
| implementation-defined. Some implementations do no additional
| translations.
`----
So. if you think using uppercase is a necessary condition to ensure
portability (while ensuring it works!), you are mistaken :)
--
Madhu
PS: Is there some documented/undocumented way to modify t-l-p behaviour
in allegro?
On Sep 28, 7:12 am, Madhu <·······@meer.net> wrote:
> * (Pascal J. Bourguignon) <··············@hubble.informatimago.com> :
> Wrote on Sat, 27 Sep 2008 08:40:37 +0200:
> |
> | I fail to see the point of using logical pathname if it is not to do
> | it in a manner that is strictly and portably standard conformant.
>
> There may be NO WAY to do this; Especially if TRANSLATE-LOGICAL-PATHNAME
> is required and you use uppercase in your logical pathname strings.
>
> | C/USER1[23]> (let* ((to-wildcard-base
> | (concatenate 'string (namestring (user-homedir-pathname))
> | "**/*"))
> | (to-wildcard-with-ext
> | (concatenate 'string to-wildcard-base
> | ".*.*")))
>
> Aside: This sort of concatenating physical pathnames as strings is
> implementation specific. To be portable you have to use.
>
> (let* ((to-wildcard-base
> (merge-pathnames
> (make-pathname :host nil :name :wild :type nil :version nil
> :directory '(:relative :wild-inferiors))
> (user-homedir-pathname) nil))
> (to-wildcard-with-ext
> (merge-pathnames
> (make-pathname :host nil :name :wild :type :wild :version :wild
> :directory '(:relative :wild-inferiors))
> (user-homedir-pathname) nil)))
>
> [supersede fixes this above code to do what the OP intended]
>
> | (setf (logical-pathname-translations "HOME")
> | `(("**;*" ,to-wildcard-base)
> | (";**;*" ,to-wildcard-base)
> | ("**;*.*.*" ,to-wildcard-with-ext)
>
> <snip>
>
> | C/USER1[27]> (parse-namestring "HOME:FOO.LISP")
> | #P"HOME:FOO.LISP" ;
> | 13
>
> => #P"HOME:FOO.LISP", 13
>
> so far so good
>
> | C/USER1[28]> (translate-logical-pathname "HOME:FOO.LISP")
> | #P"/home/pjb/foo.lisp"
>
> If you're after ~/foo.lisp you cannot use "HOME:FOO.LISP" to refer to
> this file with allegro. You have to use "HOME:foo.lisp" as your logical
> pathname.
>
> * (translate-logical-pathname "HOME:FOO.LISP")
>
> => #P"/home/madhu/FOO.LISP"
>
> * (lisp-implementation-version)
>
> => "8.1 [Linux (x86)] (Aug 9, 2008 1:00)"
>
> This is not a bug in Allegro.
>
> Function TRANSLATE-LOGICAL-PATHNAME
> ,----
> | translate-logical-pathname might perform additional translations,
> | typically to provide translation of file types to local naming
> | conventions, to accomodate physical file systems with limited length
> | names, or to deal with special character requirements such as
> | translating hyphens to underscores or uppercase letters to
> | lowercase. Any such additional translations are
> | implementation-defined. Some implementations do no additional
> | translations.
> `----
>
> So. if you think using uppercase is a necessary condition to ensure
> portability (while ensuring it works!), you are mistaken :)
> --
> Madhu
>
> PS: Is there some documented/undocumented way to modify t-l-p behaviour
> in allegro?
very good points. As a shameless plug, I would encourage people to
have a look at http://common-lisp.net/project/names-and-paths (with
particular attention devoted to the footnotes regarding TOPS-20 :) )
Cheers
--
Marco
Madhu <·······@meer.net> writes:
> Aside: This sort of concatenating physical pathnames as strings is
> implementation specific. To be portable you have to use.
>
> (let* ((to-wildcard-base
> (merge-pathnames
> (make-pathname :host nil :name :wild :type nil :version nil
> :directory '(:relative :wild-inferiors))
> (user-homedir-pathname) nil))
> (to-wildcard-with-ext
> (merge-pathnames
> (make-pathname :host nil :name :wild :type :wild :version :wild
> :directory '(:relative :wild-inferiors))
> (user-homedir-pathname) nil)))
Thanks. I replaced my earlier version with this one. It helps to clarify
what all the asterisks actually stand for in the strings. I've had a
hard time finding documentation for the syntax.
--
Steven E. Harris
Madhu <·······@meer.net> writes:
> * (Pascal J. Bourguignon) <··············@hubble.informatimago.com> :
> Wrote on Sat, 27 Sep 2008 08:40:37 +0200:
> |
> | I fail to see the point of using logical pathname if it is not to do
> | it in a manner that is strictly and portably standard conformant.
>
> There may be NO WAY to do this; Especially if TRANSLATE-LOGICAL-PATHNAME
> is required and you use uppercase in your logical pathname strings.
Yes. Just use only logical pathname to both write and read the file
system, never try to access any other file (with logical pathnames).
> [...]
>
> | C/USER1[28]> (translate-logical-pathname "HOME:FOO.LISP")
> | #P"/home/pjb/foo.lisp"
>
> If you're after ~/foo.lisp you cannot use "HOME:FOO.LISP" to refer to
> this file with allegro. You have to use "HOME:foo.lisp" as your logical
> pathname.
>
> * (translate-logical-pathname "HOME:FOO.LISP")
>
> => #P"/home/madhu/FOO.LISP"
I know this allegro specific behavior.
If you're after ~/foo.lisp, you shouldn't use logical pathnames.
> * (lisp-implementation-version)
>
> => "8.1 [Linux (x86)] (Aug 9, 2008 1:00)"
>
> This is not a bug in Allegro.
>
> Function TRANSLATE-LOGICAL-PATHNAME
> ,----
> | translate-logical-pathname might perform additional translations,
> | typically to provide translation of file types to local naming
> | conventions, to accomodate physical file systems with limited length
> | names, or to deal with special character requirements such as
> | translating hyphens to underscores or uppercase letters to
> | lowercase. Any such additional translations are
> | implementation-defined. Some implementations do no additional
> | translations.
> `----
>
> So. if you think using uppercase is a necessary condition to ensure
> portability (while ensuring it works!), you are mistaken :)
No. What it implies is that you shouldn't use logical pathname to
access portably random files created outside of lisp.
Notice how an implementation is allowed to apply rot13 or anything
else as silly (such as not mapping uppercase to lowercase on unix) to
the logical pathname when it translates them.
If you want to use logical-pathname portably, then you can use them
only to access files you created from same lisp, with same logical
pathnames.
--
__Pascal Bourguignon__ http://www.informatimago.com/
This is a signature virus. Add me to your signature and help me to live.
In article <··············@hubble.informatimago.com>,
···@informatimago.com (Pascal J. Bourguignon) wrote:
> Madhu <·······@meer.net> writes:
>
> > * (Pascal J. Bourguignon) <··············@hubble.informatimago.com> :
> > Wrote on Sat, 27 Sep 2008 08:40:37 +0200:
> > |
> > | I fail to see the point of using logical pathname if it is not to do
> > | it in a manner that is strictly and portably standard conformant.
> >
> > There may be NO WAY to do this; Especially if TRANSLATE-LOGICAL-PATHNAME
> > is required and you use uppercase in your logical pathname strings.
>
> Yes. Just use only logical pathname to both write and read the file
> system, never try to access any other file (with logical pathnames).
>
> > [...]
> >
> > | C/USER1[28]> (translate-logical-pathname "HOME:FOO.LISP")
> > | #P"/home/pjb/foo.lisp"
> >
> > If you're after ~/foo.lisp you cannot use "HOME:FOO.LISP" to refer to
> > this file with allegro. You have to use "HOME:foo.lisp" as your logical
> > pathname.
> >
> > * (translate-logical-pathname "HOME:FOO.LISP")
> >
> > => #P"/home/madhu/FOO.LISP"
>
>
> I know this allegro specific behavior.
>
> If you're after ~/foo.lisp, you shouldn't use logical pathnames.
>
>
> > * (lisp-implementation-version)
> >
> > => "8.1 [Linux (x86)] (Aug 9, 2008 1:00)"
> >
> > This is not a bug in Allegro.
> >
> > Function TRANSLATE-LOGICAL-PATHNAME
> > ,----
> > | translate-logical-pathname might perform additional translations,
> > | typically to provide translation of file types to local naming
> > | conventions, to accomodate physical file systems with limited length
> > | names, or to deal with special character requirements such as
> > | translating hyphens to underscores or uppercase letters to
> > | lowercase. Any such additional translations are
> > | implementation-defined. Some implementations do no additional
> > | translations.
> > `----
> >
> > So. if you think using uppercase is a necessary condition to ensure
> > portability (while ensuring it works!), you are mistaken :)
>
> No. What it implies is that you shouldn't use logical pathname to
> access portably random files created outside of lisp.
>
> Notice how an implementation is allowed to apply rot13 or anything
I haven't seen any implementation using rot13.
> else as silly (such as not mapping uppercase to lowercase on unix) to
> the logical pathname when it translates them.
>
>
> If you want to use logical-pathname portably, then you can use them
> only to access files you created from same lisp, with same logical
> pathnames.
That's the theory. Practically they work for more
use cases. I use logical pathnames in several Common Lisp
implementations to access source code, compiled files and
other files. The purpose of logical pathnames is to
access files independent of the physical location and
the hierarchical structure. In practice this means
that there are lots of compromises and problems. But
it also works for a lot of cases, where the files are
not 'created from the same Lisp'.
This is old stuff and may not be applicable anymore or
fallen out of fashion, or no longer being understood - nevertheless
it was quite useful. Typically one had Lisp systems
running in a networked environment with different
hosts providing local and networked file systems
(like Unix on NFS, Unix & FTP, Lispm & FTP, Lispm & NFS,
files stored on a CDROM exported by NFS on some host,
Macs with local and remote file systems and so on).
Typically the files of the Lispm are accessed via
logical hosts. The application usually will put a
system description in a central directory and will have a logical
pathname description. Sometimes the files may be spread
over several hosts: documentations on one host, code on another,
data on yet another. This configuration may be different
from host to host or site to site. Today I may have
several different Lisps running on the same machine accessing
some local and remote files. I may have two development
machines and several deployment machines. Logical pathnames
will make it possible to use one pathname syntax and
one hierarchical structure in the software. That's the use.
If the standard is poor or poorly worded, we should
make the best of it and not believe the Lisp implementation
will ROT13 the pathnames - that's bullshit - sorry.
Actually there is old documentation that describes the
use of logical pathnames - personally I find them
useful and use them still today. If under some strict
reading of the ANSI CL spec the implementations I use
are suddenly not useful anymore - I don't care that much
I have to say. There are some parts in the spec that
don't make sense by reading the spec character by character,
but by using actual implementations with the intended
behavior. If some implementations fail to provide useful
interpretations - I tend to ignore those. Sorry.
--
http://lispm.dyndns.org/
* (Pascal J. Bourguignon) <··············@hubble.informatimago.com> :
Wrote on Sun, 28 Sep 2008 11:15:26 +0200:
| Madhu <·······@meer.net> writes:
|
|> * (Pascal J. Bourguignon) <··············@hubble.informatimago.com> :
|> Wrote on Sat, 27 Sep 2008 08:40:37 +0200:
|> |
|> | I fail to see the point of using logical pathname if it is not to do
|> | it in a manner that is strictly and portably standard conformant.
|>
|> There may be NO WAY to do this; Especially if TRANSLATE-LOGICAL-PATHNAME
|> is required and you use uppercase in your logical pathname strings.
|
| Yes. Just use only logical pathname to both write and read the file
| system, never try to access any other file (with logical pathnames).
I disagree with this. Rainer is on the dot here.
| I know this allegro specific behavior.
|
| If you're after ~/foo.lisp, you shouldn't use logical pathnames.
Thats nonsense. The whole point is to define a translation to access
physical pathnames using logical pathnames. I can define the mapping of
"HOME:foo.lisp" => "~/foo.lisp" inside the translations.
The specific scenario you suggest where an application will want to 1)
create files and 2) only read those created files and no others are
comparitively few. All that can be said is that LPNs in the spec cover
this scenario.
|> * (lisp-implementation-version)
|>
|> => "8.1 [Linux (x86)] (Aug 9, 2008 1:00)"
|>
|> This is not a bug in Allegro.
|>
|> Function TRANSLATE-LOGICAL-PATHNAME
|> ,----
|> | translate-logical-pathname might perform additional translations,
|> | typically to provide translation of file types to local naming
|> | conventions, to accomodate physical file systems with limited length
|> | names, or to deal with special character requirements such as
|> | translating hyphens to underscores or uppercase letters to
|> | lowercase. Any such additional translations are
|> | implementation-defined. Some implementations do no additional
|> | translations.
|> `----
|>
|> So. if you think using uppercase is a necessary condition to ensure
|> portability (while ensuring it works!), you are mistaken :)
|
| No. What it implies is that you shouldn't use logical pathname to
| access portably random files created outside of lisp.
|
| Notice how an implementation is allowed to apply rot13 or anything
| else as silly (such as not mapping uppercase to lowercase on unix) to
| the logical pathname when it translates them.
Note: Allegro is the only implementation that does NOT frob the case of
the specified pathname in ANY WAY. I find that useful behaviour. The
fact that other implementations frob the name during translation is the
problem[1].
| If you want to use logical-pathname portably, then you can use them
| only to access files you created from same lisp, with same logical
| pathnames.
I'm unable coming up with enough sarcasm to parody this meaning of
"strictly and portably standard conformant", so I'll leave it at that
--
Madhu :)
[1] imo because they misweigh the imporatance of what the says about
uppercase in the implementation choices open to them.
From: Richard M Kreuter
Subject: Re: parse-namestring and logical pathnames
Date:
Message-ID: <874p40bal2.fsf@progn.net>
Madhu <·······@meer.net> writes:
> Allegro is the only implementation that does NOT frob the case of
> the specified pathname in ANY WAY. I find that useful behaviour.
> The fact that other implementations frob the name during translation
> is the problem[1].
<snip>
> [1] imo because they misweigh the imporatance of what the says about
> uppercase in the implementation choices open to them.
I disagree. The intent of the lettercase stuff in the pathnames
specification is to let you say
(make-pathname :name "FOO" :type "LISP" :case :common)
on any Lisp and with any pathname host and get back a pathname that
maps to a filename using the standard file naming conventions of
whatever file system the file happens to be on (i.e., "FOO.LISP" on
TOPS-20, "foo.lisp" on Unix). Failing to map uppercase in LPNs or
common case in MAKE-PATHNAME to lowercase on Unix pointlessly
reinvents the portability problems that common case and LPNs were
intended to solve.
--
RmK
On Sep 28, 4:37 pm, Richard M Kreuter <·······@progn.net> wrote:
> Madhu <·······@meer.net> writes:
> > Allegro is the only implementation that does NOT frob the case of
> > the specified pathname in ANY WAY. I find that useful behaviour.
> > The fact that other implementations frob the name during translation
> > is the problem[1].
> <snip>
> > [1] imo because they misweigh the imporatance of what the says about
> > uppercase in the implementation choices open to them.
>
> I disagree. The intent of the lettercase stuff in the pathnames
> specification is to let you say
>
> (make-pathname :name "FOO" :type "LISP" :case :common)
>
> on any Lisp and with any pathname host and get back a pathname that
> maps to a filename using the standard file naming conventions of
> whatever file system the file happens to be on (i.e., "FOO.LISP" on
> TOPS-20, "foo.lisp" on Unix). Failing to map uppercase in LPNs or
> common case in MAKE-PATHNAME to lowercase on Unix pointlessly
> reinvents the portability problems that common case and LPNs were
> intended to solve.
Mentioning TOPS-20 in *any* discussion involving pathanames is beneath
contempt. :)
Besides, lowercasing in Unix is wrong as the file system is case-
sensitive.
Cheers
--
Marco
From: Richard M Kreuter
Subject: Re: parse-namestring and logical pathnames
Date:
Message-ID: <87zllsjk3f.fsf@progn.net>
Marco Antoniotti <·······@gmail.com> writes:
> On Sep 28, 4:37 pm, Richard M Kreuter <·······@progn.net> wrote:
>> The intent of the lettercase stuff in the pathnames specification
>> is to let you say
>>
>> (make-pathname :name "FOO" :type "LISP" :case :common)
>>
>> on any Lisp and with any pathname host and get back a pathname that
>> maps to a filename using the standard file naming conventions of
>> whatever file system the file happens to be on
>
> Besides, lowercasing in Unix is wrong as the file system is case-
> sensitive.
Customary case is meant to be whatever lettercase is normally used in
file names on a file system, not whether the file system is
case-preserving or case-insensitive. The examples in the dictionary
entry for MAKE-PATHNAME shows and the Issue PATHNAME-COMPONENT-CASE
mentions that customary case for Unix is supposed to be lowercase.
--
Richard
On Sep 28, 6:44 pm, Richard M Kreuter <·······@progn.net> wrote:
> Marco Antoniotti <·······@gmail.com> writes:
> > On Sep 28, 4:37 pm, Richard M Kreuter <·······@progn.net> wrote:
> >> The intent of the lettercase stuff in the pathnames specification
> >> is to let you say
>
> >> (make-pathname :name "FOO" :type "LISP" :case :common)
>
> >> on any Lisp and with any pathname host and get back a pathname that
> >> maps to a filename using the standard file naming conventions of
> >> whatever file system the file happens to be on
>
> > Besides, lowercasing in Unix is wrong as the file system is case-
> > sensitive.
>
> Customary case is meant to be whatever lettercase is normally used in
> file names on a file system, not whether the file system is
> case-preserving or case-insensitive. The examples in the dictionary
> entry for MAKE-PATHNAME shows and the Issue PATHNAME-COMPONENT-CASE
> mentions that customary case for Unix is supposed to be lowercase.
Yes. And *that* is wrong (the supposition that customary case for
Unix is lowercase). Modulo what Rainer said about having different
file systems mounted on a UN*X box (or whatever box), traditional UNIX
file systems are not exclusively lowercase.
The bottom line is that - as usual - the pathname spec is lacking in
many many ways.
Cheers
--
Marco
From: Richard M Kreuter
Subject: Re: parse-namestring and logical pathnames
Date:
Message-ID: <87skrheiei.fsf@progn.net>
Marco Antoniotti <·······@gmail.com> writes:
> On Sep 28, 6:44 pm, Richard M Kreuter <·······@progn.net> wrote:
>> Marco Antoniotti <·······@gmail.com> writes:
>>> Besides, lowercasing in Unix is wrong as the file system is case-
>>> sensitive.
>>
>> Customary case is meant to be whatever lettercase is normally used in
>> file names on a file system, not whether the file system is
>> case-preserving or case-insensitive. The examples in the dictionary
>> entry for MAKE-PATHNAME shows and the Issue PATHNAME-COMPONENT-CASE
>> mentions that customary case for Unix is supposed to be lowercase.
>
> Yes. And *that* is wrong (the supposition that customary case for
> Unix is lowercase).
On the Unix hosts I've checked, the ratio of all-lowercase directory
entry names to any-uppercase directory entry names is around 5 to 1, and
that all-uppercase directory entry names make up around one
three-thousandth of the total number of names. Isn't that good enough
evidence that filenames are normally lowercase on Unix?
--
Richard
On Sep 30, 5:57 pm, Richard M Kreuter <·······@progn.net> wrote:
> Marco Antoniotti <·······@gmail.com> writes:
> > On Sep 28, 6:44 pm, Richard M Kreuter <·······@progn.net> wrote:
> >> Marco Antoniotti <·······@gmail.com> writes:
> >>> Besides, lowercasing in Unix is wrong as the file system is case-
> >>> sensitive.
>
> >> Customary case is meant to be whatever lettercase is normally used in
> >> file names on a file system, not whether the file system is
> >> case-preserving or case-insensitive. The examples in the dictionary
> >> entry for MAKE-PATHNAME shows and the Issue PATHNAME-COMPONENT-CASE
> >> mentions that customary case for Unix is supposed to be lowercase.
>
> > Yes. And *that* is wrong (the supposition that customary case for
> > Unix is lowercase).
>
> On the Unix hosts I've checked, the ratio of all-lowercase directory
> entry names to any-uppercase directory entry names is around 5 to 1, and
> that all-uppercase directory entry names make up around one
> three-thousandth of the total number of names. Isn't that good enough
> evidence that filenames are normally lowercase on Unix?
It is evidence enough that using :case :common in MAKE-PATHNAME (*)
assuming that UNIX file system is lowercase is broken.
$ touch myextremelyimportantfile
cl-prompt> (delete-file-while-not-knowing-that-I-am-on-a-UNIX-
filesystem (make-pathname :name
"MYEXTREMELYIMPORTANTFILE" :case :common))
$ touch MYCOMPLETEGARBAGE
cl-prompt> (delete-file-while-not-knowing-that-I-am-on-a-UNIX-
filesystem (make-pathname :name "MYCOMPLETEGARBAGE" :case :common))
may fail in "surprising" ways.
In any case, since UNIX file systems are case sensitive the following
passage from 19.2.2.1 applies "If the file system supports both cases,
strings given or received as pathname component values under this
protocol are to be used exactly as written. If the file system only
supports one case, the strings will be translated to that case."
Cheers
--
Marco
(*) Besides, there is also the argument, which can be argued for or
against, that MAKE-PATHNAME should *not* look at the file system to
build its result. Same for MERGE-PATHNAMES.
Marco Antoniotti <·······@gmail.com> writes:
>
> Yes. And *that* is wrong (the supposition that customary case for
> Unix is lowercase). Modulo what Rainer said about having different
> file systems mounted on a UN*X box (or whatever box), traditional UNIX
> file systems are not exclusively lowercase.
Unix isn't _exclusively_ lowercase, obviously, but it is _customarily_
lowercase. The word 'customarily' doesn't mean 'exclusively.'
> The bottom line is that - as usual - the pathname spec is lacking in
> many many ways.
True enough.
--
Robert Uhl <http://public.xdi.org/=ruhl>
...the moral of the story might be to never engage in copyright
violation unless you have an unstable friend with several thousand
nuclear warheads lying about. --Fox news, on the Sklyarov case
In article
<····································@2g2000hsn.googlegroups.com>,
Marco Antoniotti <·······@gmail.com> wrote:
> On Sep 28, 4:37�pm, Richard M Kreuter <·······@progn.net> wrote:
> > Madhu <·······@meer.net> writes:
> > > Allegro is the only implementation that does NOT frob the case of
> > > the specified pathname in ANY WAY. �I find that useful behaviour.
> > > The fact that other implementations frob the name during translation
> > > is the problem[1].
> > <snip>
> > > [1] imo because they misweigh the imporatance of what the says about
> > > uppercase in the implementation choices open to them.
> >
> > I disagree. �The intent of the lettercase stuff in the pathnames
> > specification is to let you say
> >
> > � (make-pathname :name "FOO" :type "LISP" :case :common)
> >
> > on any Lisp and with any pathname host and get back a pathname that
> > maps to a filename using the standard file naming conventions of
> > whatever file system the file happens to be on (i.e., "FOO.LISP" on
> > TOPS-20, "foo.lisp" on Unix). �Failing to map uppercase in LPNs or
> > common case in MAKE-PATHNAME to lowercase on Unix pointlessly
> > reinvents the portability problems that common case and LPNs were
> > intended to solve.
>
> Mentioning TOPS-20 in *any* discussion involving pathanames is beneath
> contempt. :)
What's wrong with TOPS-20? I see a boom in TOPS-20 systems
on the Internet. For example: http://www.panda.com/tops-20/
;-) <<<<-----------------<<<<
>
> Besides, lowercasing in Unix is wrong as the file system is case-
> sensitive.
I thought the case-sensitivity depends on the file
system (and some other magic). If you mount a case-insensitive
file system on a Unix box it does not necessarily get suddenly
case-sensitive. For example Mac OS X 10.5 is certified UNIX and has both
case-sensitive and case-insensitive file systems. If
I export one of those via NFS and someone mounts it
on her/his Solaris box it does not magically case-sensitive
or does it? Mount a PC disk on a Unix machine. Is the
file system suddenly case-sensitive? I doubt that. Mount
a SMB server on a Unix box? Case-sensitive? Probably not.
>
> Cheers
> --
> Marco
--
http://lispm.dyndns.org/
On Sep 28, 6:30 pm, Rainer Joswig <······@lisp.de> wrote:
> In article
> <····································@2g2000hsn.googlegroups.com>,
> Marco Antoniotti <·······@gmail.com> wrote:
>
>
>
> > On Sep 28, 4:37 pm, Richard M Kreuter <·······@progn.net> wrote:
> > > Madhu <·······@meer.net> writes:
> > > > Allegro is the only implementation that does NOT frob the case of
> > > > the specified pathname in ANY WAY. I find that useful behaviour.
> > > > The fact that other implementations frob the name during translation
> > > > is the problem[1].
> > > <snip>
> > > > [1] imo because they misweigh the imporatance of what the says about
> > > > uppercase in the implementation choices open to them.
>
> > > I disagree. The intent of the lettercase stuff in the pathnames
> > > specification is to let you say
>
> > > (make-pathname :name "FOO" :type "LISP" :case :common)
>
> > > on any Lisp and with any pathname host and get back a pathname that
> > > maps to a filename using the standard file naming conventions of
> > > whatever file system the file happens to be on (i.e., "FOO.LISP" on
> > > TOPS-20, "foo.lisp" on Unix). Failing to map uppercase in LPNs or
> > > common case in MAKE-PATHNAME to lowercase on Unix pointlessly
> > > reinvents the portability problems that common case and LPNs were
> > > intended to solve.
>
> > Mentioning TOPS-20 in *any* discussion involving pathanames is beneath
> > contempt. :)
>
> What's wrong with TOPS-20? I see a boom in TOPS-20 systems
> on the Internet. For example:http://www.panda.com/tops-20/
>
> ;-) <<<<-----------------<<<<
It is also ITS that should not be even thought of when talking about
Pathnames :-)
>
>
>
> > Besides, lowercasing in Unix is wrong as the file system is case-
> > sensitive.
>
> I thought the case-sensitivity depends on the file
> system (and some other magic). If you mount a case-insensitive
> file system on a Unix box it does not necessarily get suddenly
> case-sensitive. For example Mac OS X 10.5 is certified UNIX and has both
> case-sensitive and case-insensitive file systems. If
> I export one of those via NFS and someone mounts it
> on her/his Solaris box it does not magically case-sensitive
> or does it? Mount a PC disk on a Unix machine. Is the
> file system suddenly case-sensitive? I doubt that. Mount
> a SMB server on a Unix box? Case-sensitive? Probably not.
Yes. Of course. As a matter of fact, this was one of the early
comments on my document at http://common-lisp.net/project/names-and-paths;
i.e., the "host" should be thought of as either "file system" or "host
+fs".
As per the real and complex question "is the file system I see case-
sensitive or not?" my stand is that this should not be dealt with with
the rules of "19.2.2.1.2 Case in Pathname Components" but in a more
explicit way. In particular, for the cases you mention I do not think
it is possible for any CL implementation to be able to deal with it in
a sensible way using the :CASE parameter.
Cheers
--
Marco
Madhu <·······@meer.net> writes:
> * (Pascal J. Bourguignon) <··············@hubble.informatimago.com> :
> Wrote on Sun, 28 Sep 2008 11:15:26 +0200:
>
> | Madhu <·······@meer.net> writes:
> |
> |> * (Pascal J. Bourguignon) <··············@hubble.informatimago.com> :
> |> Wrote on Sat, 27 Sep 2008 08:40:37 +0200:
> |> |
> |> | I fail to see the point of using logical pathname if it is not to do
> |> | it in a manner that is strictly and portably standard conformant.
> |>
> |> There may be NO WAY to do this; Especially if TRANSLATE-LOGICAL-PATHNAME
> |> is required and you use uppercase in your logical pathname strings.
> |
> | Yes. Just use only logical pathname to both write and read the file
> | system, never try to access any other file (with logical pathnames).
>
> I disagree with this. Rainer is on the dot here.
>
> | I know this allegro specific behavior.
> |
> | If you're after ~/foo.lisp, you shouldn't use logical pathnames.
>
> Thats nonsense.
I always mean "portably", which I forgot to mention in that sentence.
But you're right, there's one way to use logical pathnames portably to
access any file which can be designated by a physical pathname in your
implementations. See below.
> The whole point is to define a translation to access
> physical pathnames using logical pathnames. I can define the mapping of
> "HOME:foo.lisp" => "~/foo.lisp" inside the translations.
A logical pathname with lowercase characters has an implementation
dependant semantics. If you are lucky, you will be able to access the
same file using that logical pathname with two different
implementations (it happens to be the case with clisp and allegro for
example), but there's no guarantee you'll be able to do so with a third one.
> The specific scenario you suggest where an application will want to 1)
> create files and 2) only read those created files and no others are
> comparitively few. All that can be said is that LPNs in the spec cover
> this scenario.
> Note: Allegro is the only implementation that does NOT frob the case of
> the specified pathname in ANY WAY. I find that useful behaviour. The
> fact that other implementations frob the name during translation is the
> problem[1].
We could agree there. What we really need is more homogeneous
processing of pathnames in the various implementations running on a
given platform.
> | If you want to use logical-pathname portably, then you can use them
> | only to access files you created from same lisp, with same logical
> | pathnames.
>
> I'm unable coming up with enough sarcasm to parody this meaning of
> "strictly and portably standard conformant", so I'll leave it at that
Yes, I try to take the specification as it is and bring it to its
logical consequences.
So the way to portably use logical pathnames to access any file
accessible with a physical pathname is to specify the translation for
each file.
(setf (logical-pathname-translations "HOME") nil
(logical-pathname-translations "HOME")
#+clisp
'(("HOME:FOO.LISP" #P"/home/pjb/foo.lisp")
("HOME:BAR.LISP" #P"/home/pjb/Bar.lisp")
("HOME:BASH.DOT" #P"/home/pjb/.bashrc")
("HOME:MYAPP.CONF" #P"/home/pjb/.MyApplication/MyApp.conf"))
#-clisp (error "Please write physical pathnames for this implementation."))
(And notice that portable use of (setf logical-pathname-translations)
needs the logical host in the left-hand-sides).
Of course, this would be better done using
LOAD-LOGICAL-PATHNAME-TRANSLATIONS.
--
__Pascal Bourguignon__ http://www.informatimago.com/
You never feed me.
Perhaps I'll sleep on your face.
That will sure show you.
On Sep 28, 3:15 pm, ····@informatimago.com (Pascal J. Bourguignon)
wrote:
> Madhu <·······@meer.net> writes:
> > * (Pascal J. Bourguignon) <··············@hubble.informatimago.com> :
> > Wrote on Sun, 28 Sep 2008 11:15:26 +0200:
>
> > | Madhu <·······@meer.net> writes:
> > |
> > |> * (Pascal J. Bourguignon) <··············@hubble.informatimago.com> :
> > |> Wrote on Sat, 27 Sep 2008 08:40:37 +0200:
> > |> |
> > |> | I fail to see the point of using logical pathname if it is not to do
> > |> | it in a manner that is strictly and portably standard conformant.
> > |>
> > |> There may be NO WAY to do this; Especially if TRANSLATE-LOGICAL-PATHNAME
> > |> is required and you use uppercase in your logical pathname strings.
> > |
> > | Yes. Just use only logical pathname to both write and read the file
> > | system, never try to access any other file (with logical pathnames).
>
> > I disagree with this. Rainer is on the dot here.
>
> > | I know this allegro specific behavior.
> > |
> > | If you're after ~/foo.lisp, you shouldn't use logical pathnames.
>
> > Thats nonsense.
>
> I always mean "portably", which I forgot to mention in that sentence.
>
> But you're right, there's one way to use logical pathnames portably to
> access any file which can be designated by a physical pathname in your
> implementations. See below.
>
> > The whole point is to define a translation to access
> > physical pathnames using logical pathnames. I can define the mapping of
> > "HOME:foo.lisp" => "~/foo.lisp" inside the translations.
>
> A logical pathname with lowercase characters has an implementation
> dependant semantics. If you are lucky, you will be able to access the
> same file using that logical pathname with two different
> implementations (it happens to be the case with clisp and allegro for
> example), but there's no guarantee you'll be able to do so with a third one.
>
> > The specific scenario you suggest where an application will want to 1)
> > create files and 2) only read those created files and no others are
> > comparitively few. All that can be said is that LPNs in the spec cover
> > this scenario.
> > Note: Allegro is the only implementation that does NOT frob the case of
> > the specified pathname in ANY WAY. I find that useful behaviour. The
> > fact that other implementations frob the name during translation is the
> > problem[1].
>
> We could agree there. What we really need is more homogeneous
> processing of pathnames in the various implementations running on a
> given platform.
Allow me to insist: http://common-lisp.net/project/names-and-paths
Cheers
--
Marco
···@informatimago.com (Pascal J. Bourguignon) writes:
> So the way to portably use logical pathnames to access any file
> accessible with a physical pathname is to specify the translation for
> each file.
Well, the issue, though, is that it is NOT the intent of the logical
pathname system to make it possible to access any file with a physical
pathname. Rather, the intent is to make it possible to access a
restricted set of names that can be reliably and portably be hosted on
any file system.
So, in that light, the intent of the logical pathname system is to allow
you to have the logical pathname:
SYS:FOO.LISP
and be able to access this on any file system. This in turn imposes
some restrictions on the names that you give to the files, since the
character set is limited.
So, to be portable, you have to make sure that, on Unix systems, you
name your files appropriately. Unfortunately, the decision on how to
map upper-case names is implementation-dependent. So the use of such
mapping really does limit the usefulness and portability of the code.
It seems to me that the restriction in the standard to using upper case
names only is to prevent one from making assumptions about whether a
target system has to be case sensitive. Although under Unix one can
distinguish between "foo.lisp" and "FOO.LISP", that isn't possible under
Windows or the traditional Mac file systems.
It would seem, therefore, that the best solution for case sensitive file
systems would be to not do any file translation and to have people use
upper case file names on Unix for any portable files. But since some
implementations downcase the logical names and others don't this won't
really work in practice, since the standard explicitly indicates that
case translations on logical names are implementation dependent.
So, the best that one can hope for, using logical pathnames, is that
they can be used to insulate the program code from differences in target
file systems. For EACH lisp implementation on a given host, the file
names might need to be different. (This is already somewhat the case
because, for example, the ".LISP" extension may be translated to ".LSP"
to accomodate files systems like, for example, DOS.
--
Thomas A. Russ, USC/Information Sciences Institute