Re: parse-namestring and logical pathnames

Madhu <enometh@xxxxxxxx> writes:

* (Pascal J. Bourguignon) <87vdwgr5qp.fsf@xxxxxxxxxxxxxxxxxxxxxxxx> :
Wrote on Sun, 28 Sep 2008 11:15:26 +0200:

| Madhu <enometh@xxxxxxxx> writes:
|
|> * (Pascal J. Bourguignon) <87bpyat7kq.fsf@xxxxxxxxxxxxxxxxxxxxxxxx> :
|> 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.
.

Relevant Pages

  • Re: parse-namestring and logical pathnames
    ... There may be NO WAY to do this; Especially if TRANSLATE-LOGICAL-PATHNAME ... is required and you use uppercase in your logical pathname strings. ... Some implementations do no additional ... over several hosts: documentations on one host, code on another, ...
    (comp.lang.lisp)
  • Re: parse-namestring and logical pathnames
    ... |> is required and you use uppercase in your logical pathname strings. ... implementations (it happens to be the case with clisp and allegro for ... Allegro is the only implementation that does NOT frob the case of ... fact that other implementations frob the name during translation is the ...
    (comp.lang.lisp)