Logical Pathnames etc.

I understand generally that a logical pathname abstracts filesystem specific naming and structure.

However I am having some grief trying to understand what the function logical-pathname-translations does. I have wandered in circles through the Hyperspec/ANSI standard for CL on this, and am thoroughly frustrated by the large number of functions and objects I encounter: pathname, namestring, logical pathname, physical pathname, pathname designator, etc. etc. Moreover none of the five texts on Cl that I own shed much light on this.

More specifically, can anyone tell me what the list of pairs in a logical-pathname-translations entry for a host is meant to accomplish? Why are there multiple pairs for a host? Where is the algorithm that uses these pairs described?

Or, point me to a good treatment of this in a book or online.

This is the first time I have found the ANSI spec to be unusably opaque. Or else I am dense on this topic.

- Phil -

psismondi wrote:I understand generally that a logical pathname abstracts filesystem specific naming and structure.

hmmm...all pathnames do that

psismondi wrote:More specifically, can anyone tell me what the list of pairs in a logical-pathname-translations entry for a host is meant to accomplish? Why are there multiple pairs for a host? Where is the algorithm that uses these pairs described?

Under "logical-pathname-translations" in the Hyperspec?!

Not sure what you're having trouble with. Each entry ("pair") is a mapping from a pathname on that host to whatever you want that path translated into (e.g., a path on some physical host...though you can go through another logical host first if you want). There are multiple entries because you can have more than one file on a host, and they might be in different places, so you need more than one mapping!

I've heard that CLtL2 has a good section on logical pathnames.

psismondi wrote:Where is the algorithm that uses these pairs described?

To answer this question directly: TRANSLATE-LOGICAL-PATHNAME says:

Pathname is first coerced to a pathname. If the coerced pathname is a physical pathname, it is returned. If the coerced pathname is a logical pathname, the first matching translation (according to pathname-match-p) of the logical pathname host is applied, as if by calling translate-pathname. If the result is a logical pathname, this process is repeated. When the result is finally a physical pathname, it is returned. If no translation matches, an error is signaled.

Those pairs are the translations, the first one is the from-wildcard and the second to-wildcard (as arguments to TRANSLATE-PATHNAME). They can be used to create a hierarchical pathname system with a different hierarchy that the one of the underlying file system.

Well, those responses give me some help. I suppose I risk picking a fight here, but very much doubt that the answer to my question as obvious as some replies seem to imply.

For example, asserting that all pathnames abstract away from a physical file system does not jump out at me from the spec. A pathname is defined as either a logical pathname or a physical pathname. A logical pathname is defined as being "implementation independent", and a physical pathname is defined as "a pathname that is not a logical pathname." This negative definition makes it necessary to do a considerable amount of tracing through the spec to find out just what aspects of a physical pathname are not common to logical pathnames. (Believe me, I am doing this RTFM work with all diligence right now.)

Moreover the spec is hardly crystal clear as to why one would be motivated to do the translations. This is probably obvious to experienced CL users, but not to me. The use of implementation independent ways of identifying a file are obvious. The use of a set of translations from logical pathname to pathnames is not self-evident. Nor is it obvious when and how the translations get invoked: must one call a function explicitly? Or does this happen automatically when logical hosts are used?

This all looks to me like a (probably useful) historical artifact of CL that bears some rough similarity to URIs in the modern age.

I'll just go ahead and make notes as I read and reread the CL spec, cltl2 etc. and try things out on my favorite CL (ccl).

Meanwhile, thanks for the help.

psismondi wrote:This is probably obvious to experienced CL users, but not to me.

Actually, not really. Zach Beane has performed an informal survey about logical pathnames some time ago, and many experienced CL users never use them. I somewhat understand how they work, but I have not actually used them yet.

psismondi wrote:The use of implementation independent ways of identifying a file are obvious. The use of a set of translations from logical pathname to pathnames is not self-evident.

When thinking about pathnames in CL one must remember that when the standard was written it was not clear that UNIX and Windows pathnames would become dominant. Logical pathnames are not so much meant to abstract over implementation differences, as underlying filesystem differences. For example, it could handle non-hierarchical or versioned filesystems. When you only care about one kind of filesystems their utility is more limited.

psismondi wrote:Moreover the spec is hardly crystal clear as to why one would be motivated to do the translations.

The most basic application, you want to access some files in some directories, but don't want to hardcode those directories paths. You could load them from somewhere into a variable, and then do MERGE-PATHNAMES everywhere, or bind *DEFAULT-PATHNAME-DEFAULTS*, but logical pathnames provide this functionality already.

psismondi wrote:Nor is it obvious when and how the translations get invoked: must one call a function explicitly? Or does this happen automatically when logical hosts are used?

They are translated automatically.

psismondi wrote:Well, those responses give me some help. I suppose I risk picking a fight here, but very much doubt that the answer to my question as obvious as some replies seem to imply.

Obviously not, since hardly anyone seems to actually understand them (but I don't understand why that is...)

psismondi wrote:For example, asserting that all pathnames abstract away from a physical file system does not jump out at me from the spec. A pathname is defined as either a logical pathname or a physical pathname.

Well, the operating system's idea of a pathname is a string; say "/home/paul/foo.lisp" or "C:\\Whatever\bar.lisp". etc. But Lisp pathnames are structures, with components (:absolute "home" "paul"), "foo", and "lisp" and so on.
So that's already independent of whatever format the string is in (i.e., using "/" for directory components, etc.)

But while you can obviously refer to a file with (:directory '(:absolute "home" "paul") :name "foo" :type "lisp") on any system, if it's not Unix the user's home directory probably isn't called "/home/paul" (or "\home\paul" or "home>paul>" or whatever the local filesystem's string format looks like). So just having a portable structure in place of the OS-specific string isn't enough.

psismondi wrote:A logical pathname is defined as being "implementation independent", and a physical pathname is defined as "a pathname that is not a logical pathname." This negative definition makes it necessary to do a considerable amount of tracing through the spec to find out just what aspects of a physical pathname are not common to logical pathnames.

Logical pathnames don't have a device component and use a limited character set (only A-Z, 0-9 and -).

psismondi wrote:Moreover the spec is hardly crystal clear as to why one would be motivated to do the translations. This is probably obvious to experienced CL users, but not to me. The use of implementation independent ways of identifying a file are obvious. The use of a set of translations from logical pathname to pathnames is not self-evident.

If "[t]he use of implementation independent ways of identifying a file are obvious" then how isn't it obvious that you'd need some way of mapping those "implementation-independent ways" to actual files that the underlying OS knows how to access?

psismondi wrote:Nor is it obvious when and how the translations get invoked: must one call a function explicitly? Or does this happen automatically when logical hosts are used?

Just happens automatically.