Pathname host when merging relative pathnames

[d...@scieneer.com]

While looking into pathname issues in ASDF it has become apparent that the merging of relative pathnames is rather problematic. The usage in ASDF is to merge a relative pathname with a default base. The CL 'merge-pathnames is defined to merge a relative directory with the defaults base but will keep the specified host in this case. For example:

(merge-pathnames "TEST:;FILE.LISP" "/home/") => #P"TEST:HOME;FILE.LISP.NEWEST"
or
(merge-pathnames #p"file.lisp" #p"TEST:PATH;") => #P"/path/file.lisp"

The result is not usable because the host of the specified pathname is not necessarily applicable to the default base host.

CL requires the host in order to be able to parse the relative namestring. For example is not possible to parse the namestring ";FILE.LISP" alone.

The ASDF solution is to copy the default host when the specified directory is relative, and it defines a new function 'merge-pathnames* to do this.

CL defines *default-pathname-defaults*, and defines many functions to firstly merge an argument pathname with this, and also suggests this be the current working directory making. This makes it convenient to use relative pathnames for files based in the current working directory. However when working with multiple pathname hosts it becomes problematic using such relative pathnames because the host will not default along with the directory.

Having the host define the namestring format of the pathname seems a real plus for CL. URIs in contrast can not include a scheme in a URI reference (adding a scheme makes the URI absolute) so the full structure of a relative URI may not be parsed.

One workaround is to allow 'make-pathname to accept a host of 'nil and to not default this if supplied, so that a relative pathname could be created for which the standard merging rules would copy the host. However without the host the pathname may become unprintable, or at least fall back to a native format.

For example:
(merge-pathnames (make-pathname :host nil :defaults "TEST:;FILE.LISP") "/home/") => #P"/home/file.lisp"
(merge-pathnames (make-pathname :host nil :defaults "file.lisp") "TEST:PATH;") => #P"TEST:PATH;FILE.LISP"

Would much code break if an implementation just introduced a non-standard merging rule to copy over the host when the specified pathname directory is relative? For example:
(merge-pathnames "TEST:;FILE.LISP" "/home/") => #P"/home/file.lisp"
or
(merge-pathnames #p"file.lisp" #p"TEST:PATH;") => #P"TEST:PATH;FILE.LISP"

[d...@scieneer.com]

On Sunday, May 13, 2012 1:44:21 AM UTC+10, d...@scieneer.com wrote:
...

> One workaround is to allow 'make-pathname to accept a host of 'nil and to not default this if supplied, so that a relative pathname could be created for which the standard merging rules would copy the host. However without the host the pathname may become unprintable, or at least fall back to a native format.

Found this interesting reply by Kent M. Pitman to a post on comp.lang.lisp
regarding "Question on the role of :absolute and :relative directories and logical pathnames", https://groups.google.com/forum/?hl=en&fromgroups#!searchin/comp.lang.lisp/Question$20on$20the$20role$20of$20:absolute$20and$20:relative$20directories$20and$20logical$20pathnames

"One could have made yet another syntax for relative pathnames, independent
of file systems, but we didn't. [It's a bug in the CL pathname design, IMO,
that we require a host in pathnames. Unhosted pathnames with relative
directories would be ideal in this case, but no one but me seemed to believe
in them at the time we tried to discuss them, so it didn't happen. Pity.
I implemented hostless pathnames in Symbolics Common Lisp Macsyma and they
are VERY useful. Force-hosted pathnames lead to a lot of conceptual problems
in the pathname system that you don't realize until you've worked without
them.]"

and in a later post Kent describes an approach he used:

"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."

I guess a similar solution could be integrated by adding a flag to the host object that determines if it should be considered empty when merging a relative pathname. A namestring extension would be needed to represent this flag, such as using #p"[TEST]:;PATH;FILE.lisp" for a host used only for the purpose of parsing the namestring.

However a small change to the merging rules, to have the host copied from the defaults when the specified pathname is relative, seems a lot simpler. In other words the host of a relative pathname would be defined as present only for determining the namestring format and not to be the base for the pathname when merging. I have found that some code does break with this change, but so far it has involved calls to 'merge-pathnames that could be rewritten to use a wrapper function, say 'merge-pathnames*, to maintain compatibility.

[Pascal J. Bourguignon]

d...@scieneer.com writes:

> While looking into pathname issues in ASDF it has become apparent that the merging of relative pathnames is rather problematic. The usage in ASDF is to merge a relative pathname with a default base. The CL 'merge-pathnames is defined to merge a relative directory with the defaults base but will keep the specified host in this case. For example:
>
> (merge-pathnames "TEST:;FILE.LISP" "/home/") =>
> #P"TEST:HOME;FILE.LISP.NEWEST"
> or
> (merge-pathnames #p"file.lisp" #p"TEST:PATH;") => #P"/path/file.lisp"
>
> The result is not usable because the host of the specified pathname is not necessarily applicable to the default base host.

In both "/home/" and #P"file.lisp", the parsing of the string is
implementation dependant: they're not logical pathnames, because they're
in lower case.

> CL requires the host in order to be able to parse the relative
> namestring. For example is not possible to parse the namestring
> ";FILE.LISP" alone.

";FILE.LISP" can be parsed conformingly as a logical pathname. There's
no need for a logical pathname host here.


cl-user> (print-pathname ";FILE.LISP")
Host : nil
Device : :unspecific
Directory : (:relative)
Name : "FILE"
Type : "LISP"
Version : nil
";FILE.LISP"

cl-user> (print-pathname "FILE.LISP")
Host : :unspecific
Device : nil
Directory : nil
Name : "FILE"
Type : "LISP"
Version : nil

"FILE.LISP"


> Would much code break if an implementation just introduced a
> non-standard merging rule to copy over the host when the specified
> pathname directory is relative? For example:
> (merge-pathnames "TEST:;FILE.LISP" "/home/") => #P"/home/file.lisp"
> or
> (merge-pathnames #p"file.lisp" #p"TEST:PATH;") => #P"TEST:PATH;FILE.LISP"

Yes. Pathnames are already too underspecified, adding more uncertainty
would be bad.


There's absolutely no reason to try to change the specification in this
case. Just define your own MERGE-PATHNAMES* function.

--
__Pascal Bourguignon__ http://www.informatimago.com/
A bad day in () is better than a good day in {}.

[Madhu]

* d...@scieneer.com <960342.3.1336837461919.JavaMail.geo-discussion-forums@pbcmf4> :
Wrote on Sat, 12 May 2012 08:44:21 -0700 (PDT):

| One workaround is to allow 'make-pathname to accept a host of 'nil and
| to not default this if supplied, so that a relative pathname could be
| created for which the standard merging rules would copy the host.
| However without the host the pathname may become unprintable, or at
| least fall back to a native format.
|
| For example:
| (merge-pathnames (make-pathname :host nil :defaults "TEST:;FILE.LISP")
| "/home/") => #P"/home/file.lisp"
| (merge-pathnames (make-pathname :host nil :defaults "file.lisp")
| "TEST:PATH;") => #P"TEST:PATH;FILE.LISP"

I would recommend this approach - legalizing NIL as a PATHNAME-HOST, and
specifying these semantics. I think I tried [unsuccessfully] to defend
this on cmu-imp towards the end of 2004.

[The namestring extension with optional host syntax that you suggested
in your other post could be used in cases where host becomes
unprintable.]

| Would much code break if an implementation just introduced a
| non-standard merging rule to copy over the host when the specified
| pathname directory is relative? For example:
| (merge-pathnames "TEST:;FILE.LISP" "/home/") => #P"/home/file.lisp"
| or
| (merge-pathnames #p"file.lisp" #p"TEST:PATH;") => #P"TEST:PATH;FILE.LISP"

The first example would require additional amendment of the spec text
that define the circumstances that determine when a logical pathname
should be returned.

I believe PJB's assesment "Yes. Pathnames are already too
underspecified, adding more uncertainty would be bad." applies.

[Besides, the cost to buggy implementations is not determinable. Even on
your first example with a relative LPN and a physical absolute default,
- ACL sticks in a call to translate-logical-pathname somewhere in this
machinery, and returns a physical pathname
- LW fails on directory merging rules, ...]

Expecting reliable behaviour appears to be prohibited by design. IMO
Adding more uncertainty will certainly lead to more teeth-gnashing

--- Madhu

[d...@scieneer.com]

On Tuesday, May 15, 2012 8:44:12 AM UTC+10, Pascal J. Bourguignon wrote:

> Douglas writes:
>
> > While looking into pathname issues in ASDF it has become apparent that the merging of relative pathnames is rather problematic. The usage in ASDF is to merge a relative pathname with a default base. The CL 'merge-pathnames is defined to merge a relative directory with the defaults base but will keep the specified host in this case. For example:
> >
> > (merge-pathnames "TEST:;FILE.LISP" "/home/") =>
> > #P"TEST:HOME;FILE.LISP.NEWEST"
> > or
> > (merge-pathnames #p"file.lisp" #p"TEST:PATH;") => #P"/path/file.lisp"
> >
> > The result is not usable because the host of the specified pathname is not necessarily applicable to the default base host.
>
> In both "/home/" and #P"file.lisp", the parsing of the string is
> implementation dependant: they're not logical pathnames, because they're
> in lower case.

Yes, these are intended to be examples of implementation dependant namestrings, Unix paths, with a Unix host.

CL does allow merging pathnames with different namestring formats.

> > CL requires the host in order to be able to parse the relative
> > namestring. For example is not possible to parse the namestring
> > ";FILE.LISP" alone.
>
> ";FILE.LISP" can be parsed conformingly as a logical pathname. There's
> no need for a logical pathname host here.

";FILE.LISP" is ambiguous. It could be a unix file ";FILE" of type "LISP", or match any number of other implementation specific namestrings.

Are there CL implementations that bend 'parse-namestring to return a logical pathname for such a namestring, without a pathname-host? What do they return for "FILE.LISP"?

>
>
> cl-user> (print-pathname ";FILE.LISP")
> Host : nil
> Device : :unspecific
> Directory : (:relative)
> Name : "FILE"
> Type : "LISP"
> Version : nil
> ";FILE.LISP"
>
> cl-user> (print-pathname "FILE.LISP")
> Host : :unspecific
> Device : nil
> Directory : nil
> Name : "FILE"
> Type : "LISP"
> Version : nil
> "FILE.LISP"

It's not clear what 'print-pathname is doing, but it does not appear to be using 'cl:parse-namestring and it's making some significant assumptions about the namestring format. Perhaps it would be better named 'print-logical-pathname.

>
>
> > Would much code break if an implementation just introduced a
> > non-standard merging rule to copy over the host when the specified
> > pathname directory is relative? For example:
> > (merge-pathnames "TEST:;FILE.LISP" "/home/") => #P"/home/file.lisp"
> > or
> > (merge-pathnames #p"file.lisp" #p"TEST:PATH;") => #P"TEST:PATH;FILE.LISP"
>
> Yes. Pathnames are already too underspecified, adding more uncertainty
> would be bad.
>
>
> There's absolutely no reason to try to change the specification in this
> case. Just define your own MERGE-PATHNAMES* function.

The goal of making relative pathname usable in CL seems a good reason to me.

Sure, it is possible to write wrapper functions, but there are many other CL functions that would need a wrapper, and what design would you use? What merging rules would you use? Do you find relative pathnames usable in a CL implementation supporting multiple hosts?

Here is another example:

(with-open-file (s "/tmp/file.lisp" :direction :output :if-does-not-exist :create))

(setf (logical-pathname-translations "TEST")
'(("PATH;**;*.*.*" "/tmp/**/*.*.~*~")))

(let ((*default-pathname-defaults* #p"/tmp/"))
(probe-file #p"TEST:;FILE.LISP"))
=> NIL

With the current CL merging rules the relative pathname "TEST:;FILE.LISP" will become #P"TEST:TMP;FILE.LISP.NEWEST" (CMUCL), which is not usable. With a slight change to the merging rules it would become: "/tmp/file.lisp". The later seems far more useful. Perhaps the use of logical pathnames is confusing the issue as they are typically translated, but please keep an open mind to other possible namestring formats such as URIs that can use a wide range of hosts.

[Raymond Toy]

On 5/14/12 8:05 PM, Madhu wrote:
>
> * d...@scieneer.com <960342.3.1336837461919.JavaMail.geo-discussion-forums@pbcmf4> :
> Wrote on Sat, 12 May 2012 08:44:21 -0700 (PDT):
>
> | One workaround is to allow 'make-pathname to accept a host of 'nil and
> | to not default this if supplied, so that a relative pathname could be
> | created for which the standard merging rules would copy the host.
> | However without the host the pathname may become unprintable, or at
> | least fall back to a native format.
> |
> | For example:
> | (merge-pathnames (make-pathname :host nil :defaults "TEST:;FILE.LISP")
> | "/home/") => #P"/home/file.lisp"
> | (merge-pathnames (make-pathname :host nil :defaults "file.lisp")
> | "TEST:PATH;") => #P"TEST:PATH;FILE.LISP"
>
> I would recommend this approach - legalizing NIL as a PATHNAME-HOST, and
> specifying these semantics. I think I tried [unsuccessfully] to defend
> this on cmu-imp towards the end of 2004.

I'm too lazy to look up when it happened and I don't remember right now
why :host nil was added, but this is how cmucl merges pathnames with a
host of nil. Well, except the first result is #p"/home/FILE.LISP". (I
guess an appropriate choice of :case would make the case come out as
expected.)

Ray

[Pascal J. Bourguignon]

You're right. The two implementations I'm most used to parse it as a
logical pathname but not the others:

$ clall -r '(typep (pathname ";FILE.LISP") (quote logical-pathname))'

Armed Bear Common Lisp --> NIL
International Allegro CL Free Express Edition --> NIL
Clozure Common Lisp --> T
CLISP --> T
CMU Common Lisp --> NIL
SBCL --> NIL

>> cl-user> (print-pathname ";FILE.LISP")
>> Host : nil
>> Device : :unspecific
>> Directory : (:relative)
>> Name : "FILE"
>> Type : "LISP"
>> Version : nil
>> ";FILE.LISP"
>>
>> cl-user> (print-pathname "FILE.LISP")
>> Host : :unspecific
>> Device : nil
>> Directory : nil
>> Name : "FILE"
>> Type : "LISP"
>> Version : nil
>> "FILE.LISP"
>
> It's not clear what 'print-pathname is doing, but it does not appear
> to be using 'cl:parse-namestring and it's making some significant
> assumptions about the namestring format. Perhaps it would be better
> named 'print-logical-pathname.

It just prints the pathname components.

Yes, this is certainly a strange case.

If you want to improve things with small touches, I think there are more
urgent other cases that need specifications and/or implementation
corrections (just play a little more with pathnames and you'll see what
I mean).

Otherwise, somebody with a lot of time could write up a new
specification of CL pathnames that could:

- keep logical pathnames,

- specify how physical pathnames MUST be implemented on POSIX systems
(including the version!),

- specify how URI MUST be implemented if they're provided,

- and specify more precise rules on the interaction between logical
pathnames and physical pathnames (for example, forbiding the situation
you brought about here).


The reason why the situation above is not valid is because there's
absolutely no provision to go back from physical pathnames to logical
pathnames. (For one thing, a single physical pathname could correspond
to several logical pathnames, or to none, so the reverse merging you'd
expect could be either not unique, or just not exist).


$ clall -r \
'(lisp-implementation-version)' \
'*default-pathname-defaults*' \
'(setf (logical-pathname-translations "TEST") (quote (("PATH;**;*.*.*" "/tmp/**/*.*.~*~"))))' \
'(merge-pathnames #p"TEST:;FILE.LISP" #p"TEST:PATH;")' \
'(probe-file (merge-pathnames #p"TEST:;FILE.LISP" #p"TEST:PATH;"))' \
'(let ((*default-pathname-defaults* #p"TEST:PATH;")) (probe-file #p"TEST:;FILE.LISP"))'

Armed Bear Common Lisp --> "1.0.1"
Armed Bear Common Lisp --> #P"/tmp/"
Armed Bear Common Lisp --> ((#P"TEST:PATH;**;*.*.*" #P"/tmp/**/*.*.~*~"))
Armed Bear Common Lisp --> #P"TEST:PATH;FILE.LISP.NEWEST"
Armed Bear Common Lisp Unsupported wildcard pattern: "*.*"
Armed Bear Common Lisp No translation for #P"TEST:;FILE.LISP"
International Allegro CL Free Express Edition --> "8.2 [Linux (x86)] (Sep 11, 2010 7:36)", ("lisp_build 256")
International Allegro CL Free Express Edition --> #P"/tmp/"
International Allegro CL Free Express Edition --> (("PATH;**;*.*.*" "/tmp/**/*.*.~*~"))
International Allegro CL Free Express Edition --> #P"TEST:PATH;FILE.LISP"
International Allegro CL Free Express Edition wildcard has two *'s: "*.*"
International Allegro CL Free Express Edition No translation rule for #P"TEST:FILE.LISP"
Clozure Common Lisp --> "Version 1.8-r15286M (LinuxX8664)"
Clozure Common Lisp --> #P""
Clozure Common Lisp --> (("PATH;**;*.*.*" "/tmp/**/*.*.~*~"))
Clozure Common Lisp --> #P"TEST:PATH;FILE.LISP.newest"
Clozure Common Lisp --> NIL
Clozure Common Lisp --> NIL
CLISP --> "2.49+ (2010-07-17) (built 3542867425) (memory 3542867673)"
CLISP --> #P""
CLISP --> ((#P"TEST:PATH;**;*.*.*" "/tmp/**/*.*.~*~"))
CLISP --> #P"TEST:PATH;FILE.LISP.NEWEST"
CLISP TRANSLATE-PATHNAME: replacement pieces ((:DIRECTORY) "file" "lisp" :NEWEST) do not fit into #P"/tmp/**/*.*.~*~"
CLISP TRANSLATE-LOGICAL-PATHNAME: No replacement rule for #P"TEST:;FILE.LISP" is known.
CMU Common Lisp --> "20b (20B Unicode)"
CMU Common Lisp --> #P""
CMU Common Lisp --> (("PATH;**;*.*.*" "/tmp/**/*.*.~*~"))
CMU Common Lisp --> #P"TEST:PATH;FILE.LISP.NEWEST"
CMU Common Lisp --> #P"/tmp/file.lisp"
CMU Common Lisp Type-error in KERNEL::OBJECT-NOT-TYPE-ERROR-HANDLER: #<EXTENSIONS:SEARCH-LIST library> is not of type (OR LISP::PATTERN SYMBOL SIMPLE-BASE-STRING INTEGER)
SBCL --> "1.0.55"
SBCL --> #P"/tmp/"
SBCL --> (("PATH;**;*.*.*" "/tmp/**/*.*.~*~"))
SBCL --> #P"TEST:PATH;FILE.LISP.NEWEST"
SBCL not enough wildcards in FROM pattern to match TO pattern: #<SB-IMPL::PATTERN :MULTI-CHAR-WILD "." :MULTI-CHAR-WILD>
SBCL not enough wildcards in FROM pattern to match TO pattern: #<SB-IMPL::PATTERN :MULTI-CHAR-WILD "." :MULTI-CHAR-WILD>

[d...@scieneer.com]

On Tuesday, May 15, 2012 4:51:30 PM UTC+10, Raymond Toy wrote:
> On 5/14/12 8:05 PM, Madhu wrote:
> >

> > * Douglas <960342.3.1336837461919.JavaMail.geo-discussion-forums@pbcmf4> :

The CMUCL stores the customary case in the host object so without a host perhaps the case problems are inevitable. How do you diddle the case when making a pathname with a 'nil host given defaults that are a logical-pathname?

Perhaps this illustrates another problem with the 'nil host solution - without the host the namestring is undefined. Note Kents solution appears to keep the host but adds a flag to control merging of the host and if CMUCL used a similar solution then it would still have the host object to consult for the customary case - I don't advocate this solution just yet as a change to the merging rules seems simpler.

[Marco Antoniotti]

Just to point out a different approach, I believe that NIL as host should mean "localhost" and "localhost" should mean "an object that defines what kind of host or file-system we are talking about".

Parsing of the namestring would eventually be done according to such "host". As Pascal notes implementation differences are abounding. Without even going to logical pathnames

(pathanme-type (parse-namestring ".cshrc")) ==> ".cshrc"

or

(pathanme-type (parse-namestring ".cshrc")) ==> NIL

depending on the implementation.

A preliminary and incomplete writeup of a specification that would define "how to parse a name string on platform X" is here: http://common-lisp.net/project/names-and-paths/

It is obvious that it is a spec that "decides" one way or the other. I married to any particular choice in different degrees. What I'd like to see is a "process" where interested people can vote on this or that choice and finally settle on an agreed upon spec that implementors can (and should implement).

Cheers
--
MA

[d...@scieneer.com]

On Tuesday, May 15, 2012 5:09:13 PM UTC+10, Pascal J. Bourguignon wrote:
...

Yes, they are useful and need to be maintained.

> - specify how physical pathnames MUST be implemented on POSIX systems
> (including the version!),
>
> - specify how URI MUST be implemented if they're provided,
>
> - and specify more precise rules on the interaction between logical
> pathnames and physical pathnames (for example, forbiding the situation
> you brought about here).

The above example seems fine to me. Why shouldn't a relative pathname be able to be specified as a portable logical-pathname namestring but resolved to a base with a different host?

Trying to distinguish a 'physical pathname' may not be helpful. What is the Genera 'physical' pathname namestring? There are probably lots LISPM, FEP, etc. Some CL implementations use URIs for namestrings, and these would be mapped to a local file.

> The reason why the situation above is not valid is because there's
> absolutely no provision to go back from physical pathnames to logical
> pathnames. (For one thing, a single physical pathname could correspond
> to several logical pathnames, or to none, so the reverse merging you'd
> expect could be either not unique, or just not exist).

The above example is just merging a relative pathname with a default base - it's not that complex. I am not proposing reverse translation, and CL does not support this so it's not an issue.

CL already allows a logical pathname to be built from pieces of pathnames with alternative hosts which may well represent a 'physical' file. This seems to be a plus for CL as it has a defined representation for the directory, name, type, and version (putting aside all the incompatibilities). For example:

(setf (logical-pathname-translations "TEST")
'(("PATH;**;*.*.*" "/tmp/**/*.*.~*~")))

(make-pathname :host "TEST" :defaults "/tmp/file.lisp")
=> #P"TEST:TMP;FILE.LISP" (CMUCL)

[Madhu]

* d...@scieneer.com <1323654.278.1337067457333.JavaMail.geo-discussion-forums@pbcw8> :
Wrote on Tue, 15 May 2012 00:37:37 -0700 (PDT):

| The CMUCL stores the customary case in the host object so without a
| host perhaps the case problems are inevitable. How do you diddle the
| case when making a pathname with a 'nil host given defaults that are a
| logical-pathname?

I had assumed that if you need a host object for some implementing
pathname operation, and your pathname had a NIL host, you would use the
current *d-p-d* host.

This was sufficient for me at that time to get the merging behaviour I
needed, but I have not thought this through for novel host types (or
even URI hosts). Is it unworkable for some other reason (other than
aesthetic reasons as being clumsy...)

| Perhaps this illustrates another problem with the 'nil host solution -
| without the host the namestring is undefined. Note Kents solution
| appears to keep the host but adds a flag to control merging of the
| host and if CMUCL used a similar solution then it would still have the
| host object to consult for the customary case - I don't advocate this
| solution just yet as a change to the merging rules seems simpler.

--- Madhu

[Pascal J. Bourguignon]

Marco Antoniotti <mar...@gmail.com> writes:

> It is obvious that it is a spec that "decides" one way or the other.
> I married to any particular choice in different degrees. What I'd
> like to see is a "process" where interested people can vote on this or
> that choice and finally settle on an agreed upon spec that
> implementors can (and should implement).

The CDR (http://cdr.eurolisp.org) process can be used:

We use a light-weight process that consists of the following steps:

1. One or more authors submit a document.

2. We check that the document is a printable text document, that it
is indeed about Common Lisp, and that it does not contain
objectionable material (like porn, religious or political
statements, etc.).

3. The document will be immediately assigned a fresh CDR number that
can be used to refer to the document. We will make the document
available for an initial period, after which it will be frozen and
moved into final status, unless the authors decide to withdraw the
document during the initial period.

The important part is to write the CDR, and once it enters the "initial
period" to announce its existance and request for comment.

Eventually it'll be in final status, and they we could ask the
implementers to implement it.

Hopefully, the CDR won't need to be in oppposition with the ANSI
standard, so implementaters won't have any reason not to adopt it.

[d...@scieneer.com]

On Tuesday, May 15, 2012 8:02:36 PM UTC+10, Madhu wrote:
> * d...@scieneer.com <1323654.278.1337067457333.JavaMail.geo-discussion-forums@pbcw8> :
> Wrote on Tue, 15 May 2012 00:37:37 -0700 (PDT):
>
> | The CMUCL stores the customary case in the host object so without a
> | host perhaps the case problems are inevitable. How do you diddle the
> | case when making a pathname with a 'nil host given defaults that are a
> | logical-pathname?
>
> I had assumed that if you need a host object for some implementing
> pathname operation, and your pathname had a NIL host, you would use the
> current *d-p-d* host.
>
> This was sufficient for me at that time to get the merging behaviour I
> needed, but I have not thought this through for novel host types (or
> even URI hosts). Is it unworkable for some other reason (other than
> aesthetic reasons as being clumsy...)

When calling 'open etc it will pick up the *d-p-d* host anyway, so perhaps there is some support for this. However the host defines the pathname class, so if you define the host of a pathname with a 'nil host to be effectively the *d-p-d* host then an argument could be made that the class would need to change when the *d-p-d* host changes. It would seem simpler and more predictable if the pathname class and namestring format depended only on the state of the pathname object.

[Pascal J. Bourguignon]

d...@scieneer.com writes:

>> - and specify more precise rules on the interaction between logical
>> pathnames and physical pathnames (for example, forbiding the situation
>> you brought about here).
>
> The above example seems fine to me. Why shouldn't a relative pathname
> be able to be specified as a portable logical-pathname namestring but
> resolved to a base with a different host?
>
> Trying to distinguish a 'physical pathname' may not be helpful. What
> is the Genera 'physical' pathname namestring? There are probably lots
> LISPM, FEP, etc. Some CL implementations use URIs for namestrings, and
> these would be mapped to a local file.
>
>> The reason why the situation above is not valid is because there's
>> absolutely no provision to go back from physical pathnames to logical
>> pathnames. (For one thing, a single physical pathname could correspond
>> to several logical pathnames, or to none, so the reverse merging you'd
>> expect could be either not unique, or just not exist).
>
> The above example is just merging a relative pathname with a default
> base - it's not that complex. I am not proposing reverse
> translation, and CL does not support this so it's not an issue.
>
> CL already allows a logical pathname to be built from pieces of
> pathnames with alternative hosts which may well represent a 'physical'
> file. This seems to be a plus for CL as it has a defined
> representation for the directory, name, type, and version (putting
> aside all the incompatibilities). For example:

Yes, I may have been a little too strict. Indeed, we could specify
those operations in terms of pathname components, without requiring the
host.

> (setf (logical-pathname-translations "TEST")
> '(("PATH;**;*.*.*" "/tmp/**/*.*.~*~")))
> (make-pathname :host "TEST" :defaults "/tmp/file.lisp")
> => #P"TEST:TMP;FILE.LISP" (CMUCL)

Notice that in this example, the result logical pathname has no
translation.

[d...@scieneer.com]

On Tuesday, May 15, 2012 7:25:18 PM UTC+10, Marco Antoniotti wrote:
> Just to point out a different approach, I believe that NIL as host should mean "localhost" and "localhost" should mean "an object that defines what kind of host or file-system we are talking about".

The problem with this is that it only works when there is only one 'host or file-system we are talking about' - when the *default-pathname-defaults* host is always the "localhost". Even with logical-pathnames required by CL it fails to be useful. For example:

#+clisp (setf custom:*parse-namestring-ansi* t)

(with-open-file (s "/tmp/file.lisp" :direction :output :if-does-not-exist :create))

(setf (logical-pathname-translations "TEST")
'(("PATH;**;*.*.*" "/tmp/**/*.*.~*~")))

(let ((*default-pathname-defaults* #p"TEST:PATH;"))

(probe-file #p"/tmp/file.lisp"))
=> error (CLISP)
=> #P"/tmp/file.lisp" (SBCL)

Why not just put the "localhost" object in the pathname-host in this case, or even just an empty string may solve this problem?

> Parsing of the namestring would eventually be done according to such "host". As Pascal notes implementation differences are abounding. Without even going to logical pathnames
>
> (pathanme-type (parse-namestring ".cshrc")) ==> ".cshrc"
>
> or
>
> (pathanme-type (parse-namestring ".cshrc")) ==> NIL
>
> depending on the implementation.
>
> A preliminary and incomplete writeup of a specification that would define "how to parse a name string on platform X" is here: http://common-lisp.net/project/names-and-paths/

Thank you for the link. I'll take a look at it.

[Marco Antoniotti]

Yes. I perfectly agree. But my effort is not CDR-grade yet. Plus it is of a larger magnitude than what a CDR looked like so far.

--
MA