On Thu, Jan 13, 2011 at 5:09 PM, Pascal J. Bourguignon <firstname.lastname@example.org> wrote:
188.8.131.52.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
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 184.108.40.206.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 (220.127.116.11.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.
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)