and set it up so that I can do stuff like:

(load "demo:foo.lisp")

instead of

(load "/home/rmiles/code/lisp/source/demos/foo.lisp")

(setf (logical-pathname-translations "demo")
  '(("**;*.*"  "/home/rmiles/code/lisp/source/demos/")
    (";**;*.*" "/home/rmiles/code/lisp/source/demos/")))

  this sets up both absolute and relative logical pathnames (in that order)
  on the host DEMO to map to the same directory.

  under Allegro CL, you could also put this into sys:hosts.cl:

"demo"                '(#L"**;*.*"  #P"/home/rmiles/code/lisp/source/demos/")
                '(#L";**;*.*" #P"/home/rmiles/code/lisp/source/demos/")

  or put it in some other file and register that file as a hosts map:

(push <some-other-file> (logical-pathname-translations-database-pathnames))

  (#L is a pathname syntax that forces the string into a logical pathname.
  it turns out to be a very useful extension to the standard syntax, which
  would use #P in both cases.  not that this wouldn't work in this case.)

  it is generally a good idea to separate the logical hosts setup as much
  as possible from your other code so you won't need to recompile anything
  if you move things around.  after all, that's the purpose of this thing.

This let's you specify a tree trunk, so that you can then do stuff like:
(load "lisp:source/demos/foo.lisp")

But ACL does not have this, and I guess the right way is to use ANSI Common
Lisp to specify a seperate host for each sub-directory and keep things as
split up as possible? I've been reading the hyperspec about the pathname
stuff, but I'm pretty confused. It seems like it's possible to specify a
trunk like I did above with ext:search-list except using ANSI CL and then do
an equivalent load statement something like: (load
"lisp:source;demos;foo.lisp") ; maybe not with the ".lisp" (????)

Is this possible? Or is it best to do a seperate host each for source and
demos? Anyways, thanks again for the info. It probably should work with CMUCL
but maybe I screwed up somewhere.

Thanks again,
Rob

  CMUCL's support for logical pathnames is known to be lacking.

| I've been reading the hyperspec about the pathname stuff, but I'm pretty
| confused.  It seems like it's possible to specify a trunk like I did
| above with ext:search-list except using ANSI CL and then do an equivalent
| load statement something like: (load "lisp:source;demos;foo.lisp") ;
| maybe not with the ".lisp" (????)   Is this possible?

  yes, logical pathname hosts have directory structure.  this should be
  fairly evident from the specification, but it seems that you insist on
  trying to fit the specification into your existing mindset instead of
  trying to understand the specification.  this simply won't work.  you
  have to understand first, then apply your understanding back at what
  you were used to.

| It probably should work with CMUCL but maybe I screwed up somewhere.

  I suggest you avoid CMUCL if you want to learn about logical pathnames.

  incidentally, I disagree with some of what Allegro CL 5.0 does, as well,
  and have applied some advice to get what I think is the right way to do
  it, since I use logical pathnames extensively.

    robert> Thank you. This worked on the Redhat ACL5 I downloaded,
    robert> but does not work on the CMUCL I downloaded. However,

You're right.  That doesn't work in CMUCL.  As a work-around you can
use this instead, which should work for both CMUCL and ACL:

* (setf (logical-pathname-translations "source")
   '(("demos;**;*.*"  "/home/rmiles/code/lisp/source/demos/")
     ("demos;**;*.*" "/home/rmiles/code/lisp/source/demos/")))

* (translate-logical-pathname "source:demos;foo.lisp")
#p"/home/rmiles/code/lisp/source/demos/foo.lisp"

The question is: is the example Erik gave the correct ANSI
interpretation of the logical pathname?  If so, I'll make a note of it
and try to fix it some day.

Erik's example also fails on CLISP.

(setf (logical-pathname-translations "demo")
      `(("**;*.*" #P"home/rmiles/code/lisp/source/demos/**/*.*")))

(full-pathname #P"demo:foo.lisp")
; -> #P"home/rmiles/code/lisp/source/demos/foo.lisp"

; if you don't like your sourcefiles be cluttered by the fasl's use this:

(setf (logical-pathname-translations "demo")
      `(("**;*.fasl"  #P"home/rmiles/code/lisp/source/demos/fasl/**/*.*")
        ("**;*.*" #P"home/rmiles/code/lisp/source/demos/**/*.*")))

(full-pathname #P"demo:sub;foo.lisp") ; ->
#P"home/rmiles/code/lisp/source/demos/ sub/foo.lisp" (full-pathname
#P"demo:sub;foo.fasl") ; ->#P"home/rmiles/code/lisp/source/demos/
fasl/sub/foo.fasl"

(compile #P"demo:sub;foo.lisp")
;-> fasl created in #P"home/rmiles/code/lisp/source/demos/fasl/sub/foo.fasl"

; if the first element of a pathname is a host (like "demo") it is the only
one ; delimited by an ";" the following (subdirectories) are delimited by ":"

(full-pathname #P"demo:sub;subsub;foo.lisp")

; hope this helps,
; working with MCL on Macintosh it it somewhat more confusing because the
standard divider
; between directory-names is ":" so the obove would read like this:

(setf (logical-pathname-translations "demo")
      `(("**;*.fasl"  #P"home:rmiles:code:lisp:source:demos:fasl:**:*.*")
        ("**;*.*" #P"home:rmiles:code:lisp:source:demos:**:*.*")))

In article <75k4tr$uo...@nnrp1.dejanews.com>,

  I must admit that I don't understand the difference between your example
  and mine.  (except, that yours works on CMUCL and mine doesn't, but that
  leads me to believe in the bug that stole christmas.)

  let host be (pathname-host (parse-namestring (format nil "~A:" string))).
  now, the standard says that the first element in each list in the list of
  translations shall be parsable by (parse-namestring string host) if it is
  a logical pathname namestring (as opposed to logical pathname whose host
  is host).  this leads me to assume that there is a difference between the
  behavior of CMUCL and ACL for these three forms:

(parse-namestring "**;*.*" host)
(parse-namestring ";**;*.*" host)
(parse-namestring "demos;**;*.*" host)

  in Allegro CL 5.0 (with my patches to bring directory components in line,
  but that is immaterial here except that you won't get identical results):

NAGGUM(20): (defvar host (pathname-host (parse-namestring "source:")))
host
NAGGUM(21): (setf (logical-pathname-translations host) nil)
nil
NAGGUM(22): (describe (parse-namestring "**;*.*" host))
#p"source:**;*.*" is a structure of type logical-pathname.  It has these slots:
 host               "source"
 device             nil
 directory          (:absolute :wild-inferiors)
 name               :wild
 type               :wild
 version            nil
 namestring         nil
 hash               nil
 dir-namestring     "**/"
NAGGUM(23): (describe (parse-namestring ";**;*.*" host))
#p"source:;**;*.*" is a structure of type logical-pathname.  It has these slots:
 host               "source"
 device             nil
 directory          (:relative :wild-inferiors)
 name               :wild
 type               :wild
 version            nil
 namestring         nil
 hash               nil
 dir-namestring     "**/"
NAGGUM(24): (describe (parse-namestring "demos;**;*.*" host))
#p"source:demos;**;*.*" is a structure of type logical-pathname.  It has these
slots:
 host               "source"
 device             nil
 directory          (:absolute "demos" :wild-inferiors)
 name               :wild
 type               :wild
 version            nil
 namestring         nil
 hash               nil
 dir-namestring     "/demos/**/"

  this appears to be completely in line with the specification.

  I'd like to hear the evidence you found that it was not, and also your
  theories on why it supposedly helped CMUCL to have a non-wild first
  directory component.

| Erik's example also fails on CLISP.

  frankly, I'd like to know when what I think is right doesn't fail on
  CLISP.  until then, failing is the default condition, hardly worth any
  mention at all.

As far as I know, foo:bar.lisp is not meaningful as a logical pathname
reference except insofar as any partial pathname is meaningful in the
sense that it can be merged against the default to produce a full filename.
When you do foo:bar.lisp, my understanding is that you're doing
foo:something;bar.lisp where you are trusting the "something;" is what
you want.  In the examples I've seen, you're mapping all top-level dirs
in that device to the same directory, and so then it doesn't matter what
the "something;" is.because it can have no effect.  But there is still
something that makes me feel ill when I see a reference like this.
I prefer to see a logical host definition with a directory name always
just so that if someone else needs a directory, I can give them one I'm
not using.  If I map all dirs to the same dir, I leave no syntactic space
into which to partition someone else's application.

 ;;;A very simple example of setting up a logical pathname host.  No
 ;;;translations are necessary to get around file system restrictions, so
 ;;;all that is necessary is to specify the root of the physical directory
 ;;;tree that contains the logical file system.
 ;;;The namestring syntax on the right-hand side is implementation-dependent.
 (setf (logical-pathname-translations "foo")
       '(("**;*.*.*"              "MY-LISPM:>library>foo>**>")))

 ;;;Sample use of that logical pathname.  The return value
 ;;;is implementation-dependent.
 (translate-logical-pathname "foo:bar;baz;mum.quux.3")
 =>  #P"MY-LISPM:>library>foo>bar>baz>mum.quux.3"

To do the equivalent in unix you would do something like:
(setf (logical-pathname-translations "foo")
      '(("**;*.*.*"              "MY-UNIX:/library/foo/**/")))

And it seems that CMUCL's results more closely resemble what we see in the
HyperSpec. Here's with CMUCL:
* (translate-logical-pathname "foo:bar;baz;mum.quux.3")
#p"my-unix:library/foo/bar/baz/mum.quux.3"

And here's with ACL5:
USER(4): (translate-logical-pathname "foo:bar;baz;mum.quux.3")
#p"MY-UNIX:/library/foo/bar/baz/mum.quux"

Note the missing '.3' from the end of the string ACL5 returned. Now what
would be the _standard_defined_ way to get the 3 at the end to work with
ACL5, and why didn't it work in ACL5 like it did with CMUCL, and if this can
be slightly modified to work with ACL5 and CMUCL, would it then break the
LISPM, MCL, and Lispworks versions, which I don't have around to play with to
make sure?

Rob

    Erik>   I must admit that I don't understand the difference between your example
    Erik>   and mine.  (except, that yours works on CMUCL and mine doesn't, but that
    Erik>   leads me to believe in the bug that stole christmas.)

I don't understand either.  It was just a workaround to make it work
on CMUCL.  I have no idea if it works on ACL.

    Erik> (parse-namestring "**;*.*" host)
    Erik> (parse-namestring ";**;*.*" host)
    Erik> (parse-namestring "demos;**;*.*" host)

    Erik>   in Allegro CL 5.0 (with my patches to bring directory components in line,
    Erik>   but that is immaterial here except that you won't get identical results):

    Erik> NAGGUM(20): (defvar host (pathname-host (parse-namestring "source:")))
    Erik> host
    Erik> NAGGUM(21): (setf (logical-pathname-translations host) nil)
    Erik> nil
    Erik> NAGGUM(22): (describe (parse-namestring "**;*.*" host))
    Erik> #p"source:**;*.*" is a structure of type logical-pathname.  It has these slots:
    Erik>  host               "source"
    Erik>  device             nil
    Erik>  directory          (:absolute :wild-inferiors)
    Erik>  name               :wild
    Erik>  type               :wild
    Erik>  version            nil
    Erik>  namestring         nil
    Erik>  hash               nil
    Erik>  dir-namestring     "**/"

CMUCL says

* (describe (parse-namestring "**;*.*" host))
#.(logical-pathname "SOURCE:**;*.*") is a structure of type LOGICAL-PATHNAME.
HOST: #<COMMON-LISP::LOGICAL-HOST {72BABBD}>.
DEVICE: :UNSPECIFIC.
DIRECTORY: (:ABSOLUTE :WILD-INFERIORS).
NAME: :WILD.
TYPE: :WILD.
VERSION: NIL.

    Erik> NAGGUM(23): (describe (parse-namestring ";**;*.*" host))
    Erik> #p"source:;**;*.*" is a structure of type logical-pathname.  It has these slots:
    Erik>  host               "source"
    Erik>  device             nil
    Erik>  directory          (:relative :wild-inferiors)
    Erik>  name               :wild
    Erik>  type               :wild
    Erik>  version            nil
    Erik>  namestring         nil
    Erik>  hash               nil
    Erik>  dir-namestring     "**/"

CMUCL says

* (describe (parse-namestring ";**;*.*" host))
#.(logical-pathname "SOURCE:;**;*.*") is a structure of type LOGICAL-PATHNAME.
HOST: #<COMMON-LISP::LOGICAL-HOST {72BABBD}>.
DEVICE: :UNSPECIFIC.
DIRECTORY: (:RELATIVE :WILD-INFERIORS).
NAME: :WILD.
TYPE: :WILD.
VERSION: NIL.

    Erik> NAGGUM(24): (describe (parse-namestring "demos;**;*.*" host))
    Erik> #p"source:demos;**;*.*" is a structure of type logical-pathname.  It has these
    Erik> slots:
    Erik>  host               "source"
    Erik>  device             nil
    Erik>  directory          (:absolute "demos" :wild-inferiors)
    Erik>  name               :wild
    Erik>  type               :wild
    Erik>  version            nil
    Erik>  namestring         nil
    Erik>  hash               nil
    Erik>  dir-namestring     "/demos/**/"

CMUCL says

* (describe (parse-namestring "demos;**;*.*" host))
#.(logical-pathname "SOURCE:DEMOS;**;*.*") is a structure of type LOGICAL-PATHNAME.
HOST: #<COMMON-LISP::LOGICAL-HOST {72BABBD}>.
DEVICE: :UNSPECIFIC.
DIRECTORY: (:ABSOLUTE "DEMOS" :WILD-INFERIORS).
NAME: :WILD.
TYPE: :WILD.
VERSION: NIL.

    Erik>   this appears to be completely in line with the specification.

CMUCL appears to match pretty much what ACL says in these examples.

    Erik>   I'd like to hear the evidence you found that it was not, and also your
    Erik>   theories on why it supposedly helped CMUCL to have a non-wild first
    Erik>   directory component.

I have no evidence---just the fact that CMUCL and ACL return different
answers for the original case (not the case examined here).  If ACL is
right, I would try to make CMUCL do the right thing too.

BTW for the original example, CMUCL says

* (setf (logical-pathname-translations "demo")
      `(("**;*.*" #P"home/rmiles/code/lisp/source/demos/**/*.*")))
* (setf host (pathname-host (parse-namestring "demo:")))
#<COMMON-LISP::LOGICAL-HOST {7180F05}>
* (describe (parse-namestring "**;*.*" host))
HOST: #<COMMON-LISP::LOGICAL-HOST {7180F05}>.
DEVICE: :UNSPECIFIC.
DIRECTORY: (:ABSOLUTE :WILD-INFERIORS).
NAME: :WILD.
TYPE: :WILD.
VERSION: NIL.
* (describe (parse-namestring ";**;*.*" host))
#.(logical-pathname "DEMO:;**;*.*") is a structure of type LOGICAL-PATHNAME.
HOST: #<COMMON-LISP::LOGICAL-HOST {7180F05}>.
DEVICE: :UNSPECIFIC.
DIRECTORY: (:RELATIVE :WILD-INFERIORS).
NAME: :WILD.
TYPE: :WILD.
VERSION: NIL.

So I guess CMUCL just doesn't like an empty part between the host and
the directory.

So you should IMHO write your software using logical-pathnames
(without probably using some of the less common features), and then
you will probably always have to tweak your translation-tables to your
particular implementations anyways.

WRT to your example:

a) I wouldn't rely on version-numbering anyway, since this is one of
   the more problematic features of logical-pathnames, as the
   currently popular filesystems don't support this kind of concept
   anymore (unlike previous OSs).  And I don't think that the
   currently ANSI CL-mandated concept of a version-number (a single
   non-negative integer) could be made to work fruitfully for advanced
   versioning filesystems, which normally support indefinit branching,
   which would need something more non-linear...

b) It seems that ACL 5 doesn't support version-numbers in
   pathname-translations...

Regs, Pierre.

  I would have shared your concern if that was what I observed.  naturally,
  mapping everything to the root would be counterproductive, but at least
  under Allegro CL, the following mapping:

(logical-pathname-translations "TDN")
=> ((#l"**;*.*" #p"/home/tdn/"))

  does not map everything to the root.  I actually use several
  subdirectories under the TDN host, some of which have their own logical
  pathname host because it is useful to differentiate between absolute and
  relative pathnames, such as for an archive whose absolute mapping is to
  the root of the date-based archive directory hierarchy, and the relative
  mapping is to the current date within that archive.  e.g.,

(logical-pathname-translations "archive")
=> ((#l";*.*" #p"archive:1998;12;23;")
    (#l"**;*.*" #p"tdn:archive;")))

  this may look funny, but the point is that the first of these is actually
  recomputed every midnight, and does not want to do the mapping that the
  constant part does.

  I get the impression that you think there should have been a **;*.* at
  the end of the destinations, too.  I have always figured they would have
  to be there.  mapping everything to a single directory seems so utterly
  pointless that I can't see why it would be the expected behavior.

#:Erik

  what do you suppose you'd do with it?  ACL 5.0 doesn't support file
  versions.  I think it'd be super neat if we could get rid of the
  braindamaged file systems semantics in Unix and set course for _real_
  file versions, the ability to make a file visible only after it had been
  closed, and the ability to abort a file creation and restore what was
  before the file was attempted.  however, as long as Unix doesn't do this,
  it would be a lot of work to support it.  I think it's worth it, so maybe
  I'll do it.

| Now what would be the _standard_defined_ way ...

  please note that a conforming implementation is allowed _not_ to support
  file versions.  I think you confuse your wish list with the standard.

  yes, it works in ACL 5.0.

| CMUCL appears to match pretty much what ACL says in these examples.

  yup, but note that the ACL I have used is slightly patched.  the regular
  version doesn't quite get directory-less logical pathnames right.

| So I guess CMUCL just doesn't like an empty part between the host and
| the directory.

  um, that's the specification of a relative pathname, dude.  if you start
  off the directory list with a string, it's absolute.  you got the results
  you should in that test case.  the problem is how CMUCL maps the result
  back to physical pathnames.  CMUCL turns a relative logical pathname into
  a physical pathname relative to the current directory.  this is quite
  extraordinarily silly behavior.

Here is a patch for CMUCL to make it work the same way as ACL.  I
tried the examples on Lispworks for Windows and they agree with ACL.

* (setf (logical-pathname-translations "demo")
  '(("**;*.*"  "/home/rmiles/code/lisp/source/demos/")
    (";**;*.*" "/home/rmiles/code/lisp/source/demos/")))
* (translate-logical-pathname "demo:foo.lisp")
#p"/home/rmiles/code/lisp/source/demos/foo.lisp"

If you can't rebuild CMUCL with this patch (probably), you can
download pathname.lisp from www.cons.org, apply the patch, extract out
the two affected functions, and put them (with the correct *package*) in
your .cmucl-init.lisp file.  That will apply the fix for you.

I don't think this patch affects any other behavior in CMUCL, but I've
only tested it against the examples in CLtL2.

If you need help, let me know.

Ray

    Erik>   um, that's the specification of a relative pathname, dude.  if you start
    Erik>   off the directory list with a string, it's absolute.  you got the results
    Erik>   you should in that test case.  the problem is how CMUCL maps the result

Which test case are we talking about here?

    Erik>   back to physical pathnames.  CMUCL turns a relative logical pathname into
    Erik>   a physical pathname relative to the current directory.  this is quite
    Erik>   extraordinarily silly behavior.

I don't quite follow this.  

Are you saying the logical pathname "demo:foo.lisp" gets mapped to a
physical pathname relative to the current directory?  I suppose that
would be true if (logical-pathname-translations "demo") was
'((";**;*.*.*" "./")), but isn't that what the translation says to do?

Anyway, I've sent a patch which makes CMUCL behave in the same way as
ACL for the original question.

  sigh.  you need to look up the meaning of relative and absolute logical
  pathnames in the specification.  you clearly do not understand this, yet
  you assume you do.  that is _bad_ karma.

  "host:name.type" is an absolute logical pathname namestring.  an absolute
  logical pathname's directory component is (:ABSOLUTE).  "host:;name.type"
  is a relative logical pathname namestring.  a logical pathname's
  directory component is either NIL or (:RELATIVE).  THIS IS OPPOSITE OF
  PHYSICAL PATHNAME NAMESTRINGS under Unix, where "foo.bar" should have a
  directory component of NIL or (:RELATIVE) when parsed, and "/foo.bar"
  should have a directory component of (:ABSOLUTE) when parsed.

  the specification of logical pathname namestring syntax is very clear.  I
  cannot fathom how you could begin to patch and hack on CMUCL without even
  reading it.

| Are you saying the logical pathname "demo:foo.lisp" gets mapped to a
| physical pathname relative to the current directory?

  "demo:foo.lisp" is an _absolute_ logical pathname.  pay attention!

| I suppose that would be true if (logical-pathname-translations "demo")
| was '((";**;*.*.*" "./")), but isn't that what the translation says to do?

  huh?  the whole point of logical pathnames is to remove the dependencies
  on locations in the file systems.  using the current working directory as
  the target of a logical pathname translation is just really stupid.

  I installed cmucl_2.4.5 on my Debian system, and this trial run shows the
  pathological¹ case, somewhat abbreviated to reduce CMUCL's overly chatty
  error-reporting:

CMU Common Lisp 18a+ release x86-linux 2.4.5 29 June 1998 cvs, running on sourcery

* (setf (logical-pathname-translations "DEMO")
'(("**;*.*" "/tmp/") (";**;*.*" "/tmp/foo/")))

(("**;*.*" "/tmp/") (";**;*.*" "/tmp/foo/"))
* (translate-logical-pathname #p"demo:x")

File-error in function TRANSLATE-LOGICAL-PATHNAME:
   No translation for #.(logical-pathname "DEMO:X")
* (translate-logical-pathname #p"demo:;x")

#p"tmp/foo/x"
* (translate-logical-pathname #p"demo:foo;x")

#p"/tmp/x"

  please note how insanely useless the translation of #p"demo:;x" is.

| Anyway, I've sent a patch which makes CMUCL behave in the same way as
| ACL for the original question.

  this is not comforting.  this is why I want to argue with people who may
  know better than me and who have real, economic concerns about making
  changes to their code before something is admitted into an implementation.

  you have not heeded my warnings that what I have shown you is not ACL 5.0
  behavior, it's the behavior of _my_patched_ ACL 5.0, because I think I
  got it right after spending a _lot_ of time on this shit, and there are
  a few minor issues in ACL 5.0 that don't rhyme with what I think, and I
  went ahead and made it make sense according to my understanding of the
  standard.  it is _not_ a resolved set of issues at Franz Inc, and they
  are understandably reluctant to make changes that will affect customer
  applications.  I really wish more "free" software was as cautious.  (this
  appears to contradict my desire to see fully conforming implementations,
  but getting there involves changes, and changes involve investments.)

  _I_ think you have just rebugged CMUCL's logical pathname handling.

  which versions of chattr support versions?

(What is it about usenet that makes people so uncivil?  Would they be so
uncivil face-to-face?)

[good description of relative and absolute logical pathnames deleted]

Thank you for explaining the difference to me.  Now I know.

In the case of technical newsgroups (which you would intuitively expect to
be *more* civil), my suspicion is that some people who frequently post
answers feel that the fact that they're volunteering assistance gives them
the right to act however they want.  They're not under any obligation to
post, so people should be satisfied with whatever they get.  As I said,
this is just my opinion, I don't know if it's actually why Erik likes to
flame so much here (especially at Sam, it seems).

Based on postings, there are some people I would like to meet because
they seem really cool.  Others, I want to meet, just so I can wring
their necks.

On the other hand, I've almost put Erik in my killfile, but I haven't,
yet.  When he's right, he's right.  You just have to snuff the blaze and
rummage around in the ashes to find any good stuff left.

In the long term, a lot of people start believing this is the 'proper'
way to behave here and begin doing so themselves.  _Then_ we have a
problem.  (Happily it hasn't reached that point on c.l.l... yet)

In a face-to-face situation we would see the reactions of the
bystanders and realize that this is _not_ the way to behave.  Even if
the uncivil ones themselves didn't see it, at least they wouldn't
recruit many new ones.  Not so on the Net.