From: Peter Van Eynde
Subject: Question on the role of :absolute and :relative directories and logical pathnames
Date:
Message-ID: <86elu9uqnf.fsf@mustyr-host.hq.fitit.be>
Hi people,
I've bumped into a problem. What is the meaning of a :relative or
:absolute directory when one is talking about logical pathames?
I think that foo:;bar;source.lisp and foo:bar;source.lisp have a
different meaning, and that the second can legally be translated (on
some unix machine) to /bar/source.lisp. Irrespective of where the
logical pathname foo points to.
Am I completely wrong or what? The examples in the hyperspec often use
:absolute directories when I would suspect (from the text) that they
should use :relative one's...
Groetjes, Peter
--
It's logic Jim, but not as we know it. | ········@debian.org
"God, root, what is difference?" - Pitr|
"God is more forgiving." - Dave Aronson| http://cvs2.cons.org/~pvaneynd/
From: Erik Naggum
Subject: Re: Question on the role of :absolute and :relative directories and logical pathnames
Date:
Message-ID: <3197726566938696@naggum.net>
* Peter Van Eynde
> I've bumped into a problem. What is the meaning of a :relative or
> :absolute directory when one is talking about logical pathames?
Whether they match one translation rule or another.
> I think that foo:;bar;source.lisp and foo:bar;source.lisp have a
> different meaning, and that the second can legally be translated (on some
> unix machine) to /bar/source.lisp. Irrespective of where the logical
> pathname foo points to.
That seems very, very dubious.
#:Erik
--
I found no peace in solitude.
I found no chaos in catastrophe.
-- :wumpscut:
From: Kent M Pitman
Subject: Re: Question on the role of :absolute and :relative directories and logical pathnames
Date:
Message-ID: <sfw8zkhc4n1.fsf@world.std.com>
Peter Van Eynde <········@debian.org> writes:
> I've bumped into a problem. What is the meaning of a :relative or
> :absolute directory when one is talking about logical pathames?
Same as for any other pathname. Ignore the syntax and think of the object
structure. The meaning of a relative pathname is that if you do
(merge-pathnames p1 p2)
and p1 is relative, the directory part of p2 matters; otherwise (for
absolute pathnames), the directory part of p2 is ignored.
So...
(merge-pathnames (make-pathname :directory (cons :relative dirnames)
:name "FOO"
:type "LISP"
:case :common)
(make-pathname :directory dirspec
:name "BAR"
:type "TEXT"
:case :common))
yields the same as
(make-pathname :directory (append dirspec dirnames)
:name "FOO" :type "LISP" :case :common)
while
(merge-pathnames (make-pathname :directory (cons :absolute dirnames)
:name "FOO"
:type "LISP"
:case :common)
(make-pathname :directory dirspec
:name "BAR"
:type "TEXT"
:case :common))
yields the same as
(make-pathname :directory dirnames
:name "FOO" :type "LISP" :case :common)
The fact that it's a logical host or not is wholly irrelevant to the meaning
in any kind of abstract sense. What matters is the structure of the tokens.
This is what the whole pathname system is about--getting you out of worrying
about syntax, which is highly implementation-specific, and into worrying
about symbol manipulation, which is a lot less implementation-specific (one
might wish it were not at all implementation-specific, but that's a very
hard goal).
[Of course, if the first pathname has :directory NIL, then the dirspec
in the second pathname still matters. One might argue that a dirspec
of NIL was also a relative pathname, but I'm not going to make that case
here.]
It is true that if you were to try to take a relative pathname and merge
it against null defaults, you'd be stuck in an odd situation, but that isn't
the *purpose* of a relative pathname. A relative pathname is a lot like it
is in HTML files--a notation for moving up and down in a virtual hierarchy.
So, for example, in html it is good to do:
<a href="foo.html">stuff</a>
or
<img src="images/foo.gif" />
so that your page can be tested locally as C:/somedir/index.html and the
above references will resolve to C:/somedir/foo.html and
C:/somedir/images/foo.gif, but when you install this on
http://somehost/index.html
the identical references will refer to http://somehost/foo.html
and http://somehost/images/foo.gif.
In logical hosting in Lisp, you get two degrees of freedom, not just one,
so it may be more confusing. You can both make the root be relative to
the system and you can make pages relative to one another.
So if you had an application that used references to pages in an html-like
style, you could do
((A :HREF "FOO.HTML") ...)
or
((A :HREF ";IMAGES;FOO.GIF") ...)
and it would give you a relative pathname for using against wherever you
had put these pages in your logical host, and you could move a block of
those pages around in your logical host without injury to the block of pages,
while at the same time you could move the logical host itself around in the
physical tree without loss of meaning.
From: Martin ``rydis'' Rydstr|m
Subject: Re: Question on the role of :absolute and :relative directories and logical pathnames
Date:
Message-ID: <xf1pudthv5e.fsf@licia.dtek.chalmers.se>
>>>>> "PVE" == Peter Van Eynde <········@debian.org> writes:
PVE> I've bumped into a problem. What is the meaning of a :relative or
PVE> :absolute directory when one is talking about logical pathames?
If I understood them correctly, :absolute means "absolute relative to the
base of the translation for the logical host", whereas :relative could vary
with working directories and so on.
PVE> I think that foo:;bar;source.lisp and foo:bar;source.lisp have a
PVE> different meaning, and that the second can legally be translated (on
PVE> some unix machine) to /bar/source.lisp. Irrespective of where the
PVE> logical pathname foo points to.
No, I don't think it could. Or, well, maybe it /could/, but that'd be a
rather extreme reading of a vague spec. (Based on what I have been able
to glance from the HyperSpec.)
You define the translation, both for relative and absolute logical
pathnames, and I see very little point in having the implementation not
care about the translation for the "absolute translation".
PVE> Am I completely wrong or what? The examples in the hyperspec often use
PVE> :absolute directories when I would suspect (from the text) that they
PVE> should use :relative one's...
Logical pathnames seem very interesting, but every time I try to really
understand, I get either very confused or very disappointed. They guarantee
very little. (I had as a minor idea for something to learn from to get
versions working with first Emacs-style ".~n~"-extensions, and possibly
extend that with RCS/CVS-aware handling. CMU CL wouldn't let me translate
stuff from ".~n~" to ".n" (because of the #\~, I guess) so it's on ice
right now.)
Regards,
'mr
--
Martin Rydstr|m, ·····@cd.chalmers.se ; rationalize till I'm blue in the face,
; you cannot lose if you throw the race.
Looking for a LispM to play with. Any and all offers/ideas appreciated.
Also - " - job - " - - " -
From: Erik Naggum
Subject: Re: Question on the role of :absolute and :relative directories and logical pathnames
Date:
Message-ID: <3197727478989642@naggum.net>
* Martin ``rydis'' Rydstr|m <·····@cd.chalmers.se>
> If I understood them correctly, :absolute means "absolute relative to the
> base of the translation for the logical host", whereas :relative could vary
> with working directories and so on.
Yes, it could, but it has nothing to with that.. :absolute or :relative
_only_ affect which translation rule applies. Any meaning you might
think of is relative to the value of logical-pathname-translations for
the relevant host, not an absolute.
> PVE> I think that foo:;bar;source.lisp and foo:bar;source.lisp have a
> PVE> different meaning, and that the second can legally be translated (on
> PVE> some unix machine) to /bar/source.lisp. Irrespective of where the
> PVE> logical pathname foo points to.
>
> No, I don't think it could. Or, well, maybe it /could/, but that'd be a
> rather extreme reading of a vague spec. (Based on what I have been able
> to glance from the HyperSpec.)
>
> You define the translation, both for relative and absolute logical
> pathnames, and I see very little point in having the implementation not
> care about the translation for the "absolute translation".
Well, actually, in a pathological translation rule, you _might_ get that
result, but then it would be intended by the programmer.
> Logical pathnames seem very interesting, but every time I try to really
> understand, I get either very confused or very disappointed.
The problem is probably that you don't view them sufficiently abstractly
but want to _do_ stuff with them. This generally fails. They are like
URLs: don't say squat about anything specific, but are just "locators"
and depend entirely on the translations for their meaning.
#:Erik
--
I found no peace in solitude.
I found no chaos in catastrophe.
-- :wumpscut:
From: Martin ``rydis'' Rydstr|m
Subject: Re: Question on the role of :absolute and :relative directories and logical pathnames
Date:
Message-ID: <xf1g0emig2p.fsf@licia.dtek.chalmers.se>
>>>>> "EN" == Erik Naggum <····@naggum.net> writes:
EN> * Martin ``rydis'' Rydstr|m <·····@cd.chalmers.se>
>> Logical pathnames seem very interesting, but every time I try to really
>> understand, I get either very confused or very disappointed.
EN> The problem is probably that you don't view them sufficiently abstractly
EN> but want to _do_ stuff with them. This generally fails. They are like
EN> URLs: don't say squat about anything specific, but are just "locators"
EN> and depend entirely on the translations for their meaning.
Well, that is possibly a problem, but not really the major one. It's more
along the lines of permissible characters, how to translate certain things
CMU CL doesn't know about; stuff like that. What I thought would be really
easy, along the lines of
(setf (logical-host-translations "versions")
'(("*.*.newest" "/u/rydis/test/*.*")
("*.*.*" "/u/rydis/test/*.*.~*~")))
turned out to be somewhat more work, that I really don't know how to do.
Regards,
'mr
--
Martin Rydstr|m, ·····@cd.chalmers.se ; rationalize till I'm blue in the face,
; you cannot lose if you throw the race.
Looking for a LispM to play with. Any and all offers/ideas appreciated.
Also - " - job - " - - " -
From: Daniel Barlow
Subject: Re: Question on the role of :absolute and :relative directories and logical pathnames
Date:
Message-ID: <87hey1k843.fsf@noetbook.telent.net>
Kent M Pitman <······@world.std.com> writes:
> As a rule, the Symbolics system is very sound. Pity. The one design error
> I insist they made was to insist that pathnames be hosted.
It's only after playing with this for a while that I realise just how
annoying it is. If
(parse-namestring "foo")
creates a pathname with a host, then
(merge-pathnames #p"foo" #p"scratch:bar;")
(where "scratch" names a known logical host) will create a pathname
whose host is the host of *default-pathname-defaults*, not a pathname
on "scratch". Not at all what I was expecting.
While we're here, anyone want to take a guess as to the meaning of
"... returns a logical pathname if and only if its first argument is a
logical pathname, or its first argument is a logical pathname
namestring with an explicit host, or its first argument does not
specify a host and the default-pathname is a logical pathname."
If a hostless pathname is impossible, does this mean that the third
case there can never happen anyway, or does it mean that
merge-pathnames treats a string differently from a pathname in the
first argument? It's a pathname designator, so I would find that
somewhat counterintuitive. Still, these are pathnames, nobody said
anything about it having to be intuitive.
For entertainment value, I asked people to try it out in various
implementations:
(setf (logical-pathname-translations "scratch")
'(("**;*.*.*" "/usr/local/doc/**/*")))
(pathname-host *default-pathname-defaults*)
SBCL: #<SB-IMPL::UNIX-HOST {28019B25}>
LW: NIL
ACL: NIL
So on two of three implementations we probably get an unspecified host
in #p"foo" anyway. Is this defined behvaiour?
(merge-pathnames #p"foo" "scratch:bar;")
SBCL: #P"/bar/foo"
ACL5: #p"scratch:bar;foo"
Lispworks: #P"SCRATCH:BAR;FOO"
In SBCL, pathname has a host, so don't merge the default.
In ACL5 and Lispworks, it doesn't (clever), so we do.
(merge-pathnames "foo" "scratch:bar;")
SBCL: #.(CL:LOGICAL-PATHNAME "SCRATCH:BAR;FOO")
ACL5: #p"scratch:bar;foo"
Lispworks: #P"SCRATCH:FOO"
OK, so Lispworks has parsed "foo" using LPN parsing rules there.
ACL hasn't.
(merge-pathnames ";foo" "scratch:bar;")
SBCL: #.(CL:LOGICAL-PATHNAME "SCRATCH:BAR;FOO")
ACL5: #p"scratch:bar;foo"
Lispworks: #P"SCRATCH:BAR;FOO"
I'm not sure what to conclude from this other than "don't do that,
then". Is anyone actually _using_ ANSI logical pathnames? In my
present annoyed and frustrated state, I'd be prepared to claim that it
seems like an appallingly large amount of stuff to learn for what on
most current platforms seems to provide little more useful
functionality than the moral equivalent of a $PREFIX environment
variable.
-dan
--
http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources
From: Kent M Pitman
Subject: Re: Question on the role of :absolute and :relative directories and logical pathnames
Date:
Message-ID: <sfwitihmxv3.fsf@world.std.com>
Daniel Barlow <···@telent.net> writes:
> Kent M Pitman <······@world.std.com> writes:
>
> > As a rule, the Symbolics system is very sound. Pity. The one design error
> > I insist they made was to insist that pathnames be hosted.
>
> It's only after playing with this for a while that I realise just how
> annoying it is. [ example removed ] Not at all what I was expecting.
Right.
> While we're here, anyone want to take a guess as to the meaning of
>
> "... returns a logical pathname if and only if its first argument is a
> logical pathname, or its first argument is a logical pathname
> namestring with an explicit host, or its first argument does not
> specify a host and the default-pathname is a logical pathname."
This text would mean different things depending on where you took it from.
You don't happen to mention that. I'd comment if you did.
> [...]
> (pathname-host *default-pathname-defaults*)
> SBCL: #<SB-IMPL::UNIX-HOST {28019B25}>
> LW: NIL
> ACL: NIL
I seem to recall (though a quick check didn't find it) that there is a
restriction somewhere that says you can't use NIL as a representation
for the host component to represent localhost if there is any chance
that you could have any host value other than NIL. (A lot of
implementations had chosen NIL as their "host" because they had no
ability to talk to other hosts and we didn't want to break them.)
Probably that phrasing was written before the logical host text was
inserted and the contradiction not reconciled by the time we finished
the standard. I think in the presence of logical hosts, one can't
reasonably use NIL as the value for host because logical pathnames are
required and there is an unresolvable ambiguity in some of the cases
you later cite.
> So on two of three implementations we probably get an unspecified host
> in #p"foo" anyway. Is this defined behvaiour?
>
> (merge-pathnames #p"foo" "scratch:bar;")
>
> SBCL: #P"/bar/foo"
> ACL5: #p"scratch:bar;foo"
> Lispworks: #P"SCRATCH:BAR;FOO"
This has to do with the NIL host above. Implementations having no logical
hosts nor other external hosts would never see this bug because merging or
not merging NIL hosts would come out the same. But once there are two hosts
possible, NIL must not be a value.
> I'm not sure what to conclude from this other than "don't do that,
> then".
I'll omit the other examples. I think the choice of NIL to mean
"localhost" is the source of most of this confusion, but I've had too
little sleep to really check these thoroughly. See if that historical
information doesn't help you clear it up.
> Is anyone actually _using_ ANSI logical pathnames?
Sure, but I almost always do a merge of explicit pathnames where I control
the content and particularly where I copy the host from wherever I want
it to come from because I know about the design bug in the merging of hosts.
e.g.,
(merge-pathnames (make-pathname :host (pathname-host pathname2 :case :common)
:case :common :defaults pathname1)
pathname2)
That usually doesn't run into problems such as you're having. Of course,
you have to know at program-design time which pathname will be the one to
believe on the host. The alternative is to do like I did in Common Lisp
Macsyma for Symbolics and do:
(defstruct mpathname
pathname
host-component-empty-p)
and then write a set of operations that know how to tell when the host has
been legitimately supplied and when it should be treated as if NIL.
> In my
> present annoyed and frustrated state, I'd be prepared to claim that it
> seems like an appallingly large amount of stuff to learn for what on
> most current platforms seems to provide little more useful
> functionality than the moral equivalent of a $PREFIX environment
> variable.
No, it actually provides a huge amount of benefit. Just not in the case of
cross-host merging. The other thing you probably don't know you can do
is to pass a :defaults to MAKE-PATHNAME and a default to PARSE-NAMESTRING.
Between these two, you can assure that you never end up with namestrings that
aren't tightly bonded to an appropriate host.
Merging cross-host-type doesn't work well, but if you're working exclusively
with logical pathnames, then instead of (merge-pathnames "foo" ...) you can
do (merge-pathnames (parse-namestring "foo" *my-logical-host*) ...) or
(merge-pathnames (parse-namestring "foo" nil *my-logical-path*) ...).
In both of those cases, you'll get something that has the right host in it
so it won't lose when you merge it with other logical hosts.
From: Marco Antoniotti
Subject: Re: Question on the role of :absolute and :relative directories and logical pathnames
Date:
Message-ID: <y6cwv6x8tm2.fsf@octagon.mrl.nyu.edu>
Kent M Pitman <······@world.std.com> writes:
> Daniel Barlow <···@telent.net> writes:
>
> > Kent M Pitman <······@world.std.com> writes:
> >
> > > As a rule, the Symbolics system is very sound. Pity. The one design error
> > > I insist they made was to insist that pathnames be hosted.
> >
...
> > "... returns a logical pathname if and only if its first argument is a
> > logical pathname, or its first argument is a logical pathname
> > namestring with an explicit host, or its first argument does not
> > specify a host and the default-pathname is a logical pathname."
>
> This text would mean different things depending on where you took it from.
> You don't happen to mention that. I'd comment if you did.
...
> > So on two of three implementations we probably get an unspecified host
> > in #p"foo" anyway. Is this defined behvaiour?
> >
> > (merge-pathnames #p"foo" "scratch:bar;")
> >
> > SBCL: #P"/bar/foo"
> > ACL5: #p"scratch:bar;foo"
> > Lispworks: #P"SCRATCH:BAR;FOO"
>
> This has to do with the NIL host above. Implementations having no logical
> hosts nor other external hosts would never see this bug because merging or
> not merging NIL hosts would come out the same. But once there are two hosts
> possible, NIL must not be a value.
Apart from the merging problem, (I do not have an ACL or a LW system
handy right now) what it the TYPE of the ACL and LW results? Are they
PATHNAMEs or LOGICAL-PATHNAMEs?
...
> with logical pathnames, then instead of (merge-pathnames "foo" ...) you can
> do (merge-pathnames (parse-namestring "foo" *my-logical-host*) ...) or
> (merge-pathnames (parse-namestring "foo" nil *my-logical-path*) ...).
> In both of those cases, you'll get something that has the right host in it
> so it won't lose when you merge it with other logical hosts.
Unfortunately you do not have this luxury many times. :(
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.