From: ············@gmail.com
Subject: logical pathname translations
Date: 
Message-ID: <1114939492.149505.52340@o13g2000cwo.googlegroups.com>
1) should

("myhost:**;*" "/Files/**/*")

translate "myhost:x;y" to "/Files/x/y"? In my reading, it should not,
but the only lisp that signals an error is Allegro Common Lisp, all
others do the translation, mixing pathname-type NIL and pathname-type
:WILD.

2) what should (pathname-type "myhost:**;*.") (the trailing dot) yield?

From: Christophe Rhodes
Subject: Re: logical pathname translations
Date: 
Message-ID: <sqvf63p5aw.fsf@cam.ac.uk>
·············@gmail.com" <············@gmail.com> writes:

> 1) should
>
> ("myhost:**;*" "/Files/**/*")
>
> translate "myhost:x;y" to "/Files/x/y"? In my reading, it should not,
> but the only lisp that signals an error is Allegro Common Lisp, all
> others do the translation, mixing pathname-type NIL and pathname-type
> :WILD.

Why?

Firstly, the rules for TRANSLATE-LOGICAL-PATHNAME says that the it
uses the rules for PATHNAME-MATCH-P to determine whether a
from-pathname matches; PATHNAME-MATCH-P specifies that missing
(i.e. NIL) components of a wildcard are treated as :WILD.  So, on the
assumption that you in fact have a logical-host named "MYHOST", the
first rule applies when the from-pathname matches any directory, any
name, any type and any version.  So the translator is applicable for
something with :NAME "Y" :TYPE NIL.

Secondly, physical namestring parsing is completely, and I mean
completely, undefined according to the standard.  There is no standard
interpretation of the namestring "/Files/**/*", so implementations are
free to do whatever they like.

A better translation list might be

  (list "MYHOST:**;*" (make-pathname :directory '(:absolute "Files" :wild-inferiors)
                                     :name :wild :type nil :version nil))

and in that case maybe implementations should signal errors, but I
still wouldn't want to bet on it.

Also, in addition to implementations being allowed to parse physical
namestrings as they like, I believe they are also allowed to perform
canonizations internally.  So, if at any point you're getting results
that you don't understand, be sure to inspect the pathnames very
carefully.

> 2) what should (pathname-type "myhost:**;*.") (the trailing dot) yield?

A parse error.  See section 19.3.1 of the spec.  (Rare are the
occasions that such a definitive answer can be given to a pathname
question).

Christophe
From: ············@gmail.com
Subject: Re: logical pathname translations
Date: 
Message-ID: <1114956306.769246.168290@f14g2000cwb.googlegroups.com>
Christophe Rhodes wrote:
> ·············@gmail.com" <············@gmail.com> writes:
>
> > 1) should
> >
> > ("myhost:**;*" "/Files/**/*")
> >
> > translate "myhost:x;y" to "/Files/x/y"? In my reading, it should
not,
> > but the only lisp that signals an error is Allegro Common Lisp, all
> > others do the translation, mixing pathname-type NIL and
pathname-type
> > :WILD.
>
> Why?
>
> Firstly, the rules for TRANSLATE-LOGICAL-PATHNAME says that the it
> uses the rules for PATHNAME-MATCH-P to determine whether a
> from-pathname matches; PATHNAME-MATCH-P specifies that missing
> (i.e. NIL) components of a wildcard are treated as :WILD.  So, on the
> assumption that you in fact have a logical-host named "MYHOST", the
> first rule applies when the from-pathname matches any directory, any
> name, any type and any version.  So the translator is applicable for
> something with :NAME "Y" :TYPE NIL.

What should

(pathname-match-p "myhost:**;" "myhost:x;y")

return? None of implementations available for me returns T. Why is type
different from name?

>
> Secondly, physical namestring parsing is completely, and I mean
> completely, undefined according to the standard.

This is irrelevant to my question, sorry. I might as well have an
Easter greeting there.

>
> > 2) what should (pathname-type "myhost:**;*.") (the trailing dot)
yield?
>
> A parse error.  See section 19.3.1 of the spec.  (Rare are the
> occasions that such a definitive answer can be given to a pathname
> question).

My first reaction was the same. So, let me repeat what my text
generating experiment returned as the message subject after chewing
c.l.l archives: "Is there a working common lisp implementation?"  The
only implementation which actually signals error is CLISP (in strict
ANSI mode).

In fact, though, any pathname that does not parse as a logical pathname
is just not a logical pathname,  and any implementation is valid to
return anything implementation defined. And CLISP's message in strict
ANSI mode is problematic: it definitely follows from the attempt of
CLISP to parse it as a logical pathname.
From: Christophe Rhodes
Subject: Re: logical pathname translations
Date: 
Message-ID: <sqr7gqq3eh.fsf@cam.ac.uk>
·············@gmail.com" <············@gmail.com> writes:

> What should
>
> (pathname-match-p "myhost:**;" "myhost:x;y")
>
> return? 

NIL, obviously.

> None of implementations available for me returns T. Why is type
> different from name?

Perhaps you are thinking of the call with the arguments reversed?

  Syntax:
    pathname-match-p pathname wildcard => generalized-boolean

> Christophe Rhodes wrote:
>> > 2) what should (pathname-type "myhost:**;*.") (the trailing dot)
> yield?
>>
>> A parse error.  See section 19.3.1 of the spec.  
>
> My first reaction was the same. 

My mistake, actually.

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.

so, since "myhost:**;*." is not a syntactically valid logical pathname
namestring containing an explicit host, ...

  Otherwise, the parsing of thing is implementation-defined.

(parse-namestring "MYHOST:**;*." "MYHOST") must signal a parse-error,
but (parse-namestring "MYHOST:**;*." NIL) need not, if "MYHOST:**;*."
can be parsed as a physical pathname by the implementation.

>> (Rare are the
>> occasions that such a definitive answer can be given to a pathname
>> question).

Oh, the irony. :-/

> So, let me repeat what my text generating experiment returned as the
> message subject after chewing c.l.l archives: "Is there a working
> common lisp implementation?"  The only implementation which actually
> signals error is CLISP (in strict ANSI mode).

So, as above, a parse-error is not mandated, though it is allowed.

And, as I think I've said before in this forum, the pathname chapter
has its problems; there will be additional problems that the user
isn't expecting if they use namestrings, rather than explicit
pathnames, except in such circumstances as it is defined that it will
be parsed as a logical pathname namestring.

Christophe
From: ············@gmail.com
Subject: Re: logical pathname translations
Date: 
Message-ID: <1114968259.783200.272520@z14g2000cwz.googlegroups.com>
C> NIL, obviously.
>
> > None of implementations available for me returns T. Why is type
> > different from name?
>
> Perhaps you are thinking of the call with the arguments reversed?
>
>   Syntax:
>     pathname-match-p pathname wildcard => generalized-boolean
>

I just made a typo typing the expression into the message. LispWorks:

CL-USER 10 > (pathname-match-p "host:x;y" "host:**;")
NIL

CL-USER 11 > (pathname-match-p "host:x;y" "host:**;*")
T

CL-USER 12 > 

Why?
From: Christophe Rhodes
Subject: Re: logical pathname translations
Date: 
Message-ID: <sqmzreq2g4.fsf@cam.ac.uk>
·············@gmail.com" <············@gmail.com> writes:

> CL-USER 10 > (pathname-match-p "host:x;y" "host:**;")
> NIL
>
> CL-USER 11 > (pathname-match-p "host:x;y" "host:**;*")
> T
>
> Why?

I don't know.  Have you asked Lispworks, Inc?  I believe they have
such things as support channels.  For what it's worth, both forms
return T in SBCL; given the state of incompletion of the pathnames
chapter in the standard I wouldn't want to claim that it's the
unambiguously right answer.

Christophe
From: Pascal Bourguignon
Subject: Re: logical pathname translations
Date: 
Message-ID: <87fyx6eho9.fsf@thalassa.informatimago.com>
·············@gmail.com" <············@gmail.com> writes:

> C> NIL, obviously.
>>
>> > None of implementations available for me returns T. Why is type
>> > different from name?
>>
>> Perhaps you are thinking of the call with the arguments reversed?
>>
>>   Syntax:
>>     pathname-match-p pathname wildcard => generalized-boolean
>>
>
> I just made a typo typing the expression into the message. LispWorks:
>
> CL-USER 10 > (pathname-match-p "host:x;y" "host:**;")
> NIL
>
> CL-USER 11 > (pathname-match-p "host:x;y" "host:**;*")
> T
>
> CL-USER 12 > 
>
> Why?

Because the first matches a directory and host:x;y isn't a (path to a) directory,
while the second matches a file andhost:x;y is a (path to a) file

(pathname-match-p "host:x;y;" "host:**;")  will return T.


-- 
__Pascal Bourguignon__                     http://www.informatimago.com/
Until real software engineering is developed, the next best practice
is to develop with a dynamic system that has extreme late binding in
all aspects. The first system to really do this in an important way
is Lisp. -- Alan Kay
From: ············@gmail.com
Subject: Re: logical pathname translations
Date: 
Message-ID: <1115025532.910440.106070@o13g2000cwo.googlegroups.com>
> > Why?
>
> Because the first matches a directory and host:x;y isn't a (path to
a) directory,
> while the second matches a file andhost:x;y is a (path to a) file
>
> (pathname-match-p "host:x;y;" "host:**;")  will return T.


but the specification says missing components are treated as wildcards,
that is, host:**; and host:**;* and host:**;*.* are the same wildcards
-- that's what Christiane's saying. Are they?
From: Christophe Rhodes
Subject: Re: logical pathname translations
Date: 
Message-ID: <sqoebugeh3.fsf@cam.ac.uk>
·············@gmail.com" <············@gmail.com> writes:

> but the specification says missing components are treated as wildcards,
> that is, host:**; and host:**;* and host:**;*.* are the same wildcards
> -- that's what Christiane's saying. Are they?
                 ^^^^^^^^^^

Um, was that meant to be my name?  

In any case, I think Pascal has failed to read either this thread or
the specification in sufficient detail.

Christophe
From: ············@gmail.com
Subject: Re: logical pathname translations
Date: 
Message-ID: <1115027059.125313.173630@l41g2000cwc.googlegroups.com>
> Um, was that meant to be my name?
> 

Hi Christophe,

my apologies, I should have been careful.

David