[Ecls-list] Problem with pathnames

[Pascal J. Bourguignon]

Juan Jose Garcia-Ripoll
<juanjose.garciaripoll at googlemail.com> writes:

> On Thu, Jan 13, 2011 at 5:09 PM, Pascal J. Bourguignon <pjb at informatimago.com> wrote:
>
>     19.2.2.2.3.1 is even more specific, specifying that both :unspecific and
>     nil should be converted to namestrings without the component.
>     >From this, I would expect an implementation on unix to accept
>     :unspecific and cause no problem with unix pathnames.
>
> I believe the clarifying point is here in CLtL
>
> http://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node204.html#SECTION002711000000000000000
> Programming hint: portable programs should be prepared to handle the
> value :unspecific in the device, directory, type, or version field in
> some implementations. Portable programs should not explicitly place
> :unspecific in any field because it might not be permitted in some
> situations, but portable programs may sometimes do so implicitly (by
> copying such a value from another pathname, for example).
>
> Regarding Section 19.2.2.2.3.1 and file operations, ECL so far has
> adopted the convention that only pathnames which can be printed
> readably can be "opened". In other words, each file has associated a
> unique absolute physical pathname (not namestring)
>
> Precisely because of what you mention (19.2.2.2.3.1), pathnames with
> :unspecific can not be printed readably. If one decides that #p"foo"
> represents a file with :TYPE NIL, then it can not represent a file
> with :TYPE :UNSPECIFIC
>
> That is unrelated to namestrings, though the ECL routine
> ecl_namestring() has an option to stop translating a pathname when it
> finds that it can not be printed readably.
>
> Maybe this is not a wise choice but it is consistent. I am open to
> other possibilities and not too incompatible changes.


19.2.2.2.3 :UNSPECIFIC as a Component Value

    When writing[1] the value of any pathname component, the
    consequences are undefined if :unspecific is given for a pathname in
    a file system for which it does not make sense. 

ECL could define that :unspecific doesn't make sense for types, and
could define that it is mapped to NIL.  ie.  pathname-type could never
return :unspecific (and similarly for other components).


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