I am bogged down by the behavior of logical pathnames wrt word case.
The Hyperspec says that lowercase letters are translated into
uppercase when parsing 'word' and 'wildcard-word's (19.3.1.1.7)
I have the following directory
TOP
which is tied to the LP "TOP:" by setf'ing
LOGICAL-PATHNAME-TRANSLATIONS. So far so good.
Now here is the trick. Before setting up the LPs I used some
'mixed-case' names, like
TOP.system
(which contains.... guess what ?!? ... a DEFSYSTEM form :) )
Unfortunately, the translation process yields
* (translate-logical-pathname "TOP:TOP.system")
#p"/users/marcoxa/lang/cl/TOP/top.system"
which denotes a file that does not exist. (Note also that the
translated pathname has everything lowercase).
Am I the only one having a problem with this behavior? Is there a
quick way out to convince TRANSLATE-LOGICAL-PATHNAME to eventually
produce a name that actually matches that of a file on the File
System?
Cheers
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa
······@2xtreme.net (Christopher R. Barry) writes:
> Marco Antoniotti <·······@copernico.parades.rm.cnr.it> writes:
>
> > * (translate-logical-pathname "TOP:TOP.system")
> > #p"/users/marcoxa/lang/cl/TOP/top.system"
>
> USER(50): (setf (logical-pathname-translations "TOP")
> '(("**;*.*.*" #p"/users/marcoxa/lang/cl/TOP/")))
> (("**;*.*.*" #p"/users/marcoxa/lang/cl/TOP/"))
>
> USER(51): (translate-logical-pathname "TOP:TOP.system")
> #p"/users/marcoxa/lang/cl/TOP/TOP.system"
>
> USER(52): (make-pathname :host "TOP" :name "TOP.system" :case :local)
> #p"TOP:TOP.system"
>
> USER(53): (translate-logical-pathname *)
> #p"/users/marcoxa/lang/cl/TOP/TOP.system"
>
This is ACL behavior. CMUCL and Harlequin LW PE seem to disagree and
to stick by the uppercasing rule of the Hyperspec.
BTW. I found a decent patch in my case.
(setf (logical-pathname-translations "TOP")
'(("TOP.SYSTEM" #p"/users/marcoxa/lang/cl/TOP/TOP.system")
("**;*.*.*" #p"/users/marcoxa/lang/cl/TOP/")))
I have a hunch that according to the Hyperspec this is the "most"
correct solution.
BTW. Here is another one for you all.
What should
(pathname-version (pathname "TOP:anyfile"))
return?
I couldn't find anything relevant in the Hyperspec. I kind of assume
that a MERGE-PATHNAME with *DEFAULT-PATHNAME-DEFAULTS* should be
happening in the midst, but I am not sure.
Cheers
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa
On 1999-06-30 11:17 +0200,
Marco Antoniotti wrote:
[...]
> BTW. Here is another one for you all.
>
> What should
>
> (pathname-version (pathname "TOP:anyfile"))
>
> return?
NIL?
> I couldn't find anything relevant in the Hyperspec. I kind of assume
> that a MERGE-PATHNAME with *DEFAULT-PATHNAME-DEFAULTS* should be
> happening in the midst, but I am not sure.
In `19.2.1.6 The Pathname Version Component':
The version is either a positive integer or a symbol from the following
list: nil, :wild, :unspecific, [...]
But `19.3.2.1 Unspecific Components of a Logical Pathname' says:
The device component of a logical pathname is always :unspecific; no
other component of a logical pathname can be :unspecific.
Therefore the value returned by PATHNAME-VERSION when the version
is missing should be NIL, moreover that:
19.2.2.2.1 NIL as a Component Value
As a pathname component value, nil represents that the component
is ``unfilled''; see Section 19.2.3 (Merging Pathnames).
The value of any pathname component can be nil.
Maybe that helps some.
Vassil Nikolov
Permanent forwarding e-mail: ········@poboxes.com
For more: http://www.poboxes.com/vnikolov
Abaci lignei --- programmatici ferrei.
Vassil Nikolov <········@poboxes.com> writes:
>
> On 1999-06-30 11:17 +0200,
> Marco Antoniotti wrote:
>
> > (pathname-version (pathname "TOP:anyfile"))
>
> In `19.2.1.6 The Pathname Version Component':
>
> The version is either a positive integer or a symbol from the following
> list: nil, :wild, :unspecific, [...]
>
> But `19.3.2.1 Unspecific Components of a Logical Pathname' says:
>
> The device component of a logical pathname is always :unspecific; no
> other component of a logical pathname can be :unspecific.
>
> Therefore the value returned by PATHNAME-VERSION when the version
> is missing should be NIL, moreover that:
>
> 19.2.2.2.1 NIL as a Component Value
>
> As a pathname component value, nil represents that the component
> is ``unfilled''; see Section 19.2.3 (Merging Pathnames).
>
> The value of any pathname component can be nil.
>
> Maybe that helps some.
It might not be a logical pathname. On the Lisp Machine, <anything>:
is either a host or a logical host, depending on what's declared.
If it's a regular host, then if the host supports versioning, then
NIL will be returned for the version, but if it's not versioned,
then :unspecific will be the result. On other implementations,
top: might be a native device (e.g., consider VAX VMS) in which case
it depends on whether that device supports versioning. The only
machines I know that support devices but not versions are ITS pathnames,
where you could have either a type or a version but not both. Common
Lisp never ran on ITS, but CL could talk to ITS from a Lisp Machine,
and I'm not sure the semantics. Probably it doesn't matter. Anyway,
bottom line is that NIL or :UNSPECIFIC should theoretically be expected.
Kent M Pitman <······@world.std.com> writes:
> Vassil Nikolov <········@poboxes.com> writes:
>
> >
> > On 1999-06-30 11:17 +0200,
> > Marco Antoniotti wrote:
> >
> > > (pathname-version (pathname "TOP:anyfile"))
> >
> > In `19.2.1.6 The Pathname Version Component':
> >
> > The version is either a positive integer or a symbol from the following
> > list: nil, :wild, :unspecific, [...]
> >
> > But `19.3.2.1 Unspecific Components of a Logical Pathname' says:
> >
> > The device component of a logical pathname is always :unspecific; no
> > other component of a logical pathname can be :unspecific.
> >
> > Therefore the value returned by PATHNAME-VERSION when the version
> > is missing should be NIL, moreover that:
> >
> > 19.2.2.2.1 NIL as a Component Value
> >
> > As a pathname component value, nil represents that the component
> > is ``unfilled''; see Section 19.2.3 (Merging Pathnames).
> >
> > The value of any pathname component can be nil.
> >
> > Maybe that helps some.
>
> It might not be a logical pathname. On the Lisp Machine, <anything>:
> is either a host or a logical host, depending on what's declared.
> If it's a regular host, then if the host supports versioning, then
> NIL will be returned for the version, but if it's not versioned,
> then :unspecific will be the result. On other implementations,
> top: might be a native device (e.g., consider VAX VMS) in which case
> it depends on whether that device supports versioning. The only
> machines I know that support devices but not versions are ITS pathnames,
> where you could have either a type or a version but not both. Common
> Lisp never ran on ITS, but CL could talk to ITS from a Lisp Machine,
> and I'm not sure the semantics. Probably it doesn't matter. Anyway,
> bottom line is that NIL or :UNSPECIFIC should theoretically be expected.
Thanks to both.
It happens that this may be a CMUCL quirk. Here is the message I sent
the cmucl-imp list. I'd like an educated fix :) This is a
show-stopper for me righ now.
==============================================================================
Hi
I bumped in the following scenario
I have a logical pathname translation like
(setf (logical-pathname-translations "ZUT")
`(("ZUT-PKG.*" "/my/personal/ZUT/ZUT-pkg.*")))
(this is to circumvent the uppercasing behavior of logical pathname
strings).
On the other side, we have that
(pathname-version *default-pathname-defaults*) => :NEWEST
(I do not touch *default-pathname-defaults*)
The logical pathname translation works as expected, but now
(pathname "ZUT:ZUT-pkg") => #.(logical-pathname "ZUT:ZUT-PKG")
(pathname-version (pathname "ZUT:ZUT-pkg")) => NIL
Which, because of the call to PROBE-FILE, followed by MERGE-PATHNAMES
in LOAD, makes TRANSLATE-PATHNAME eventually barf when
(load "ZUT:ZUT-pkg")
This happens because the call to PROBE-FILE within LOAD uses a merged
pathname which is then matched, via TRANSLATE-LOGICAL-PATHNAME and
TRANSLATE-PATHANME, with the logical pathname coming from the
translation, which has a version of NIL.
I do not know whether a fix is needed or what fix is needed. Maybe
the version of *default-pathname-defaults* should be made NIL or the
default version of all newly created (logical) pathnames should be
made :NEWEST.
Any idea, or suggestion?
BTW. Harlequin LW PE is unfazed by this, while having the same
defaults. MERGE-PATHNAMES of "ZUT:ZUT-pkg" with
*default-pathname-defaults* returns a pathname with :NEWEST version.
Thanks
==============================================================================
Actually, looking back at the message, it may be that
(setf (logical-pathname-translations "ZUT")
`(("ZUT-PKG.*.*" "/my/personal/ZUT/ZUT-pkg.*.*")))
(i.e. wildcarding the version as well) could do the trick. Working
mostly on UN*X, versions are not something I usually consider.
Cheers
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa
From: Christopher R. Barry
Subject: Re: Logical Pathname Subtlety
Date:
Message-ID: <87r9mkcnt1.fsf@2xtreme.net>
Marco Antoniotti <·······@copernico.parades.rm.cnr.it> writes:
> I have a logical pathname translation like
>
> (setf (logical-pathname-translations "ZUT")
> `(("ZUT-PKG.*" "/my/personal/ZUT/ZUT-pkg.*")))
>
> (this is to circumvent the uppercasing behavior of logical pathname
> strings).
>
> On the other side, we have that
>
> (pathname-version *default-pathname-defaults*) => :NEWEST
>
> (I do not touch *default-pathname-defaults*)
>
> The logical pathname translation works as expected, but now
>
> (pathname "ZUT:ZUT-pkg") => #.(logical-pathname "ZUT:ZUT-PKG")
> (pathname-version (pathname "ZUT:ZUT-pkg")) => NIL
>
> Which, because of the call to PROBE-FILE, followed by MERGE-PATHNAMES
> in LOAD, makes TRANSLATE-PATHNAME eventually barf when
>
> (load "ZUT:ZUT-pkg")
>
> This happens because the call to PROBE-FILE within LOAD uses a merged
> pathname which is then matched, via TRANSLATE-LOGICAL-PATHNAME and
> TRANSLATE-PATHANME, with the logical pathname coming from the
> translation, which has a version of NIL.
>
> I do not know whether a fix is needed or what fix is needed. Maybe
> the version of *default-pathname-defaults* should be made NIL or the
> default version of all newly created (logical) pathnames should be
> made :NEWEST.
Unix pathnames do not have a concept of version, so the version
component of every Unix pathname should always be :UNSPECIFIC. A value
of NIL or :UNSPECIFIC should cause the component not to appear in the
namestring. The difference between choosing one or the other with
pathname components occurs in the merging operation, where NIL is
replaced with the default for that component from
*DEFAULT-PATHNAME-DEFAULTS*, while :UNSPECIFIC is left alone as though
the position were already filled. [See 19.2.2.3.1 of CLHS]
With a Unix Lisp you'll want (and in the case of Allegro get):
(pathname-version (make-pathname :version :newest))
=> :UNSPECIFIC
(setq *default-pathname-defaults*
(make-pathname :defaults *default-pathname-defaults*
:version :newest))
=> #P"/users/marcoxa/"
(pathname-version *default-pathname-defaults*)
=> :UNSPECIFIC
This behavior is conforming and will protect you from wasting your
time worrying about versions with Unix hosts.
Anyways, this does not have much to do with your original problem
concerning CMUCL's case behavior. From 19.2.2.1.2.1 "Local Case in
Pathname Components" of the CLHS:
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.
And then there is 19.3.1.1.7 "Lowercase Letters in a Logical Pathname
Namestring":
When parsing words and wildcard-words, lowercase letters are
translated to uppercase.
A definition of what a word is is in the formal definition of logical
pathname namestring syntax:
logical-pathname::= [host host-marker]
[relative-directory-marker] {directory directory-marker}*
[name] [type-marker type [version-marker version]]
host::= word
directory::= word | wildcard-word | wild-inferiors-word
name::= word | wildcard-word
type::= word | wildcard-word
version::= pos-int | newest-word | wildcard-version
[...]
word --- one or more uppercase letters, digits, and hyphens.
Per 19.3.1.1.7, the logical pathname namestrings "TOP:TOP.system" and
"TOP:TOP.SYSTEM" are equivalent.
Thus your solution is something like:
(setf (logical-pathname-translations "TOP")
'(("**;TOP.SYSTEM" #p"/users/marcoxa/lang/cl/TOP/**/TOP.system")
("**;*.*" #p"/users/marcoxa/lang/cl/TOP/**/*.*")))
This won't work with CLISP but don't even begin to try to use logical
pathnames with CLISP if you want to see behavior remotely in the
spirit of cooperation with other implementations and like the CLHS
describes. (This _does_ work with ACL, CMUCL, Symbolics....)
Note that I think Allegro CL's non-conformant behavior of not parsing
all logical pathname namestrings to uppercase is much more useful if
you only have 1/10th of the Lisp Machine's logical pathnames
implementation. (Which has stuff like FS:DEFINE-CANONICAL-TYPE that
makes case-insensitive logical-pathnames not such a pain to use.)
The beauty of translations are that once you get some logical pathname
"TOP:TOP.system" that works for you, no matter what behavior you
depend on in your implementation's parsing and processing you will be
able to find a "TOP:TOP.system" that works for you so that all your
code that depends on "TOP:TOP.system" will work with another
implementation once the translation is suitably defined.
Christopher
······@2xtreme.net (Christopher R. Barry) writes:
> Marco Antoniotti <·······@copernico.parades.rm.cnr.it> writes:
>
> > I have a logical pathname translation like
> >
> > (setf (logical-pathname-translations "ZUT")
> > `(("ZUT-PKG.*" "/my/personal/ZUT/ZUT-pkg.*")))
> >
> > (this is to circumvent the uppercasing behavior of logical pathname
> > strings).
> >
> > On the other side, we have that
> >
> > (pathname-version *default-pathname-defaults*) => :NEWEST
> >
> > (I do not touch *default-pathname-defaults*)
> >
> > The logical pathname translation works as expected, but now
> >
> > (pathname "ZUT:ZUT-pkg") => #.(logical-pathname "ZUT:ZUT-PKG")
> > (pathname-version (pathname "ZUT:ZUT-pkg")) => NIL
> >
> > Which, because of the call to PROBE-FILE, followed by MERGE-PATHNAMES
> > in LOAD, makes TRANSLATE-PATHNAME eventually barf when
> >
> > (load "ZUT:ZUT-pkg")
> >
> > This happens because the call to PROBE-FILE within LOAD uses a merged
> > pathname which is then matched, via TRANSLATE-LOGICAL-PATHNAME and
> > TRANSLATE-PATHANME, with the logical pathname coming from the
> > translation, which has a version of NIL.
> >
> > I do not know whether a fix is needed or what fix is needed. Maybe
> > the version of *default-pathname-defaults* should be made NIL or the
> > default version of all newly created (logical) pathnames should be
> > made :NEWEST.
>
> Unix pathnames do not have a concept of version, so the version
> component of every Unix pathname should always be :UNSPECIFIC. A value
> of NIL or :UNSPECIFIC should cause the component not to appear in the
> namestring. The difference between choosing one or the other with
> pathname components occurs in the merging operation, where NIL is
> replaced with the default for that component from
> *DEFAULT-PATHNAME-DEFAULTS*, while :UNSPECIFIC is left alone as though
> the position were already filled. [See 19.2.2.3.1 of CLHS]
Your interpretation makes perfect sense. Therefore, it would seem
that it is CMUCL
* (pathname-version *default-pathname-defaults*)
:NEWEST
*
that is at fault. One for cmucl-imp.
...
> Anyways, this does not have much to do with your original problem
> concerning CMUCL's case behavior. From 19.2.2.1.2.1 "Local Case in
> Pathname Components" of the CLHS:
...
> Per 19.3.1.1.7, the logical pathname namestrings "TOP:TOP.system" and
> "TOP:TOP.SYSTEM" are equivalent.
>
> Thus your solution is something like:
>
> (setf (logical-pathname-translations "TOP")
> '(("**;TOP.SYSTEM" #p"/users/marcoxa/lang/cl/TOP/**/TOP.system")
> ("**;*.*" #p"/users/marcoxa/lang/cl/TOP/**/*.*")))
>
Thanks. As a matter of fact I had already decided that that was the
way to go. A little too long, but it is a very good way to do
things. And it works (so far) under CMUCL and LW-P.Ed.
As a matter of fact I just need
(setf (logical-pathname-translations "TOP")
'(("TOP.SYSTEM.*" #p"/users/marcoxa/lang/cl/TOP/TOP.system.*")
("**;*.*.*" #p"/users/marcoxa/lang/cl/TOP/**/*.*.*")))
Also, note the wild version marker. This is a fix for the current
(wrong) behavior of CMUCL.
Thanks
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa
On 1999-07-06 17:56 +0000,
Kent M Pitman wrote:
> Vassil Nikolov <········@poboxes.com> writes:
>
> >
> > On 1999-06-30 11:17 +0200,
> > Marco Antoniotti wrote:
> >
> > > (pathname-version (pathname "TOP:anyfile"))
[me: should return NIL]
[...] ;CLHS quotes
>
> It might not be a logical pathname.
[...] ;detailed explanations including ITS and LispM and VMS behaviour
> bottom line is that NIL or :UNSPECIFIC should theoretically be expected.
The original post^1 asked specifically about logical pathnames (TOP
being a logical host), that's why I completely ignored the other case.
Which led to those interesting notes about ITS, LispM, and VMS. So
there was some benefit, at least for me.
__________
^1 Probably forgotten by now---at the time being I post through Deja's
e-mail-to-news gateway which delays posts by about 3 days (probably
not a bug but a feature to channel people via the Web interface), so
my post (like the others) was 3 days late; sorry.
Vassil Nikolov
Permanent forwarding e-mail: ········@poboxes.com
For more: http://www.poboxes.com/vnikolov
Abaci lignei --- programmatici ferrei.