If a CL system nows about the logical pathname "foo",
should (pathname "foo:test.lisp") return
a logical pathname? Even under a OS which uses colons
as valid parts of the pathname names?
--
http://www.lavielle.com/~joswig/
In article <·································@news.lavielle.com> ······@lavielle.com (Rainer Joswig) writes:
If a CL system nows about the logical pathname "foo",
should (pathname "foo:test.lisp") return
a logical pathname? Even under a OS which uses colons
as valid parts of the pathname names?
My guess would be that it could go either way.
MCL has this problem, and the way I got around it is to explicitly use
make-pathname. A little more clunky, but a lot safer than guessing which
way LISP will go.
If make-pathname is not a feasible option, I have no idea how you might
make sure.
Sunil
·······@cleon.cc.gatech.edu (Sunil Mishra) writes:
> ······@lavielle.com (Rainer Joswig) writes:
> > If a CL system nows about the logical pathname "foo",
> > should (pathname "foo:test.lisp") return
> > a logical pathname? Even under a OS which uses colons
> > as valid parts of the pathname names?
>
> My guess would be that it could go either way.
A bit of poking around in the Common Lisp HyperSpec(TM) reveals the
following, which eliminates at least a little of the guessing:
The argument to pathname is a pathname designator, which can be
various things including a pathname namestring.
The leap of faith I can't find anywhere documented, but that one has
to believe is "only rational" is that the same rules apply to
(pathname x) where x is a pathname namestring as do apply to
(parse-namestring x) i.e., with a NIL host. Strictly, I think an
implementation has wiggle room for doing the wrong thing here and
claim to still be virtuous, but it is a tenuous claim since that
virtue is hinged on the idea that the differnt namestring parsers are
deliberately being inconsistent (permitted, probably accidentally, but
not obvious why anyone would want it). I recommend reporting it as a
bug and citing the data in this message as a justification. This is
the kind of portability gotcha that drives CL programmers nuts and
there's no good reason we vendors can't work to agree on. At least,
there's no obvious underlying technical barrier (such as efficiency)
which I can see for non-agreement.
From Function PARSE-NAMESTRING:
* If host is nil and thing is a syntactically valid logical
pathname namestring containing an explicit host, then it is
parsed as a logical pathname namestring.
I think it is generally agreed among the CL designers that it's
well-defined that a logical host FOO: has precedence over a
physical host or device FOO: and so you must invent another
notation (as Symbolics Genera uses ":FOO:..." to refer to a device
named FOO on the default host) or you must arrange a host nickname
that can substitute for FOO (e.g., a fully qualified internet
name like FOO.ACME.COM) or else you should rename the logical host
to something less intrusive (which you cannot do if the logical
host is named SYS, by the way; that's the only reserved logical
host name).
> MCL has this problem, and the way I got around it is to explicitly
> use make-pathname. A little more clunky, but a lot safer than
> guessing which way LISP will go.
Yes, one of the wonderful things about Lisp is the richness of ways it
gives you to take hold even in the face of little anomalies like this.
Kent M Pitman wrote:
>
> ·······@cleon.cc.gatech.edu (Sunil Mishra) writes:
>
> > ······@lavielle.com (Rainer Joswig) writes:
> > > If a CL system nows about the logical pathname "foo",
> > > should (pathname "foo:test.lisp") return
> > > a logical pathname? Even under a OS which uses colons
> > > as valid parts of the pathname names?
> >
> > My guess would be that it could go either way.
> I think it is generally agreed among the CL designers that it's
> well-defined that a logical host FOO: has precedence over a
> physical host or device FOO:
This is what I want. Portability rules. ;-)
I want a user to be able to define a pathname in a file.
It could be either a physical or a logical pathname string
When converting this string I'd have to use something
like
(if (logical-pathname-string-p string)
(logical-pathname pathname)
(pathname string))
where I would have to define LOGICAL-PATHNAME-STRING-P
as
(let ((host-name (get-host-name-part-from-string string)))
(ignore-errors (logical-pathname-translations host-name)))
Or?
Rainer Joswig wrote:
>
> If a CL system nows about the logical pathname "foo",
> should (pathname "foo:test.lisp") return
> a logical pathname? Even under a OS which uses colons
> as valid parts of the pathname names?
>
> --
> http://www.lavielle.com/~joswig/
I had thought that (pathnames <some-string>) was equivalent to (values
(parse-namestring <some-string>)), but now I can't find the evidence to
back this up.
I think (parse-namestring "foo:test.lisp") must return a logical
pathname if "foo" is defined as a logical pathname host, because the
ANSI spec for parse-namestring says:
If host is nil and thing is a syntactically valid logical pathname
namestring containing an explicit host, then it is parsed as a logical
pathname namestring.
However, ANSI doesn't actually specify that the default for host is nil.
If one instists that the default for host is some
implementation-dependent value, than you can find ways to prove that
practically NO possible behavior of parse-namestring is defined.