[Ecls-list] Problem with pathnames

[Juan Jose Garcia-Ripoll]

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
:unspecificin 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.

Juanjo

-- 
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://juanjose.garciaripoll.googlepages.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/ecl-devel/attachments/20110113/a4df4d37/attachment.html>