291 lines
17 KiB
HTML
291 lines
17 KiB
HTML
<!-- Common Lisp HyperSpec (TM), version 7.0 generated by Kent M. Pitman on Mon, 11-Apr-2005 2:31am EDT -->
|
|
<HTML>
|
|
<HEAD>
|
|
<TITLE>CLHS: Issue PATHNAME-COMPONENT-VALUE Writeup</TITLE>
|
|
<LINK HREF="../Data/clhs.css" REL="stylesheet" TYPE="text/css" />
|
|
<META HTTP-EQUIV="Author" CONTENT="Kent M. Pitman">
|
|
<META HTTP-EQUIV="Organization" CONTENT="LispWorks Ltd.">
|
|
<LINK REL=TOP HREF="../Front/index.htm">
|
|
<LINK REL=COPYRIGHT HREF="../Front/Help.htm#Legal">
|
|
<LINK REL=DISCLAIMER HREF="../Front/Help.htm#Disclaimer">
|
|
<LINK REL=PREV HREF="../Issues/iss256_w.htm">
|
|
<LINK REL=UP HREF="../Issues/iss257.htm">
|
|
<LINK REL=NEXT HREF="../Issues/iss258_w.htm">
|
|
</HEAD>
|
|
<BODY>
|
|
<H1><A REV=MADE HREF="http://www.lispworks.com/"><IMG WIDTH=80 HEIGHT=65 ALT="[LISPWORKS]" SRC="../Graphics/LWSmall.gif" ALIGN=Bottom></A><A REL=TOP HREF="../Front/index.htm"><IMG WIDTH=237 HEIGHT=65 ALT="[Common Lisp HyperSpec (TM)]" SRC="../Graphics/CLHS_Sm.gif" ALIGN=Bottom></A> <A REL=PREV HREF="../Issues/iss256_w.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Previous]" SRC="../Graphics/Prev.gif" ALIGN=Bottom></A><A REL=UP HREF="../Issues/iss257.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Up]" SRC="../Graphics/Up.gif" ALIGN=Bottom></A><A REL=NEXT HREF="../Issues/iss258_w.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Next]" SRC="../Graphics/Next.gif" ALIGN=Bottom></A></H1>
|
|
|
|
<HR>
|
|
|
|
|
|
|
|
<H2>Issue PATHNAME-COMPONENT-VALUE Writeup</H2>
|
|
|
|
<PRE><B>Issue:</B> <A HREF="iss257.htm">PATHNAME-COMPONENT-VALUE</A><P>
|
|
<P>
|
|
Related Issues:PATHNAME-CANONICAL-TYPE,<P>
|
|
<A HREF="iss263.htm">PATHNAME-SUBDIRECTORY-LIST</A>,<P>
|
|
<A HREF="iss266.htm">PATHNAME-UNSPECIFIC-COMPONENT</A>,<P>
|
|
<A HREF="iss267.htm">PATHNAME-WILD</A><P>
|
|
<P>
|
|
<B>References:</B> CLtL pp.410-3<P>
|
|
<P>
|
|
<B>Category:</B> CLARIFICATION and CHANGE<P>
|
|
<P>
|
|
<B>Edit history:</B> Version 1, 20-Mar-89, by Moon<P>
|
|
Version 2, 9-May-89, by Moon (rewrite based on mail)<P>
|
|
Version 3, 17-Jun-89, by Moon (add discussion, current practice)<P>
|
|
<P>
|
|
<B>Problem description:<P>
|
|
</B> <P>
|
|
CLtL is overly restrictive on the possible values for <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A> components.<P>
|
|
These restrictions are described in a funny way that makes it unclear<P>
|
|
whether they are requirements, guidelines, or just an example.<P>
|
|
<P>
|
|
The restrictions are not all written down in one place, but they appear<P>
|
|
to be as follows:<P>
|
|
<P>
|
|
Host nil, :wild, string, or list of strings<P>
|
|
Device nil, :wild, string, or something else ("structured")<P>
|
|
Directory nil, :wild, string, or something else ("structured")<P>
|
|
Name nil, :wild, string, or something else ("structured")<P>
|
|
Type nil, :wild, or string<P>
|
|
Version nil, :wild, :newest, positive integer, implementation<P>
|
|
dependent symbol, or implementation-dependent integer<P>
|
|
less than or equal to zero. Suggestions include :oldest,<P>
|
|
:previous, :installed, 0, and -1.<P>
|
|
<P>
|
|
<A HREF="iss266.htm">PATHNAME-UNSPECIFIC-COMPONENT:NEW-TOKEN</A> allowed implementations to<P>
|
|
allow any component to be :UNSPECIFIC. This has been voted in.<P>
|
|
<P>
|
|
<A HREF="iss263.htm">PATHNAME-SUBDIRECTORY-LIST</A> proposes a list of strings and keyword<P>
|
|
symbols for the directory component.<P>
|
|
<P>
|
|
PATHNAME-CANONICAL-TYPE proposes some new operations but does not<P>
|
|
change the possible values of the type component.<P>
|
|
<P>
|
|
<A HREF="iss267.htm">PATHNAME-WILD</A> proposes a portable way to test for implementation<P>
|
|
dependent component values that indicate wildcard matching. It<P>
|
|
does not change the possible values of any component.<P>
|
|
<P>
|
|
<B>Proposal (PATHNAME-COMPONENT-VALUE:SPECIFY):<P>
|
|
</B><P>
|
|
The points of the proposal have been numbered/lettered to facilitate<P>
|
|
discussion of individual points.<P>
|
|
<P>
|
|
0. Pathname component value strings never contain the punctuation<P>
|
|
characters that are used to separate <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A> fields (e.g. slashes and<P>
|
|
dots in Unix). Punctuation characters appear only in namestrings.<P>
|
|
Characters used as punctuation can appear in <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A> component values<P>
|
|
with a non-punctuation meaning if the file system allows it (e.g. a Unix<P>
|
|
file name that begins with a dot).<P>
|
|
<P>
|
|
When examining <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A> components, conforming programs must be prepared<P>
|
|
to encounter any of the following values:<P>
|
|
<P>
|
|
1. Any component can be <A REL=DEFINITION HREF="../Body/a_nil.htm#nil"><B>NIL</B></A>, which means the component has not<P>
|
|
been specified.<P>
|
|
<P>
|
|
2. Any component can be :UNSPECIFIC, which means the component has<P>
|
|
no meaning in this particular <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A>.<P>
|
|
<P>
|
|
3. The device, directory, name, and type can be strings.<P>
|
|
<P>
|
|
4. The host can be any object, at the discretion of the implementation.<P>
|
|
<P>
|
|
5. The directory can be a list of strings and symbols as detailed in<P>
|
|
<A HREF="iss263.htm">PATHNAME-SUBDIRECTORY-LIST</A> (this assumes that it passes.)<P>
|
|
<P>
|
|
6. The version can be any symbol or any integer. The symbol :NEWEST<P>
|
|
refers to the largest version number that already exists in the file<P>
|
|
system when reading, overwriting, appending, superseding, or directory<P>
|
|
listing an existing file, and refers to the smallest version number<P>
|
|
greater than any existing version number when creating a new file.<P>
|
|
Other symbols and integers have implementation-defined meaning.<P>
|
|
It is suggested, but not required, that implementations use positive<P>
|
|
integers starting at 1 as version numbers, recognize the symbol :OLDEST<P>
|
|
to designate the smallest existing version number, and use keyword<P>
|
|
symbols for other special versions.<P>
|
|
<P>
|
|
Wildcard pathnames can be used with <A REL=DEFINITION HREF="../Body/f_dir.htm#directory"><B>DIRECTORY</B></A> but not with <A REL=DEFINITION HREF="../Body/f_open.htm#open"><B>OPEN</B></A>, and<P>
|
|
return true from <A REL=DEFINITION HREF="../Body/f_wild_p.htm#wild-pathname-p"><B>WILD-PATHNAME-P</B></A> (if issue <A HREF="iss267.htm">PATHNAME-WILD</A> passes). When<P>
|
|
examining wildcard components of a wildcard <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A>, conforming programs<P>
|
|
must be prepared to encounter any of the following additional values<P>
|
|
in any component or any element of a list that is the directory component:<P>
|
|
<P>
|
|
7. :WILD, which matches anything.<P>
|
|
<P>
|
|
8. A string containing implementation-dependent special wildcard<P>
|
|
characters.<P>
|
|
<P>
|
|
9. Any object, representing an implementation-dependent wildcard<P>
|
|
pattern.<P>
|
|
<P>
|
|
When constructing a <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A> from components, conforming programs<P>
|
|
must follow these rules:<P>
|
|
<P>
|
|
a. Any component can be <A REL=DEFINITION HREF="../Body/a_nil.htm#nil"><B>NIL</B></A>. <A REL=DEFINITION HREF="../Body/a_nil.htm#nil"><B>NIL</B></A> in the host may mean a default host<P>
|
|
rather than an actual <A REL=DEFINITION HREF="../Body/a_nil.htm#nil"><B>NIL</B></A> in some implementations.<P>
|
|
<P>
|
|
b. The host, device, directory, name, and type can be strings. There<P>
|
|
are implementation-dependent limits on the number and type of<P>
|
|
characters in these strings.<P>
|
|
<P>
|
|
c. The directory can be a list of strings and symbols as detailed in<P>
|
|
<A HREF="iss263.htm">PATHNAME-SUBDIRECTORY-LIST</A> (this assumes that it passes.) There are<P>
|
|
implementation-dependent limits on the list's length and contents.<P>
|
|
<P>
|
|
d. The version can be :NEWEST.<P>
|
|
<P>
|
|
e. Any component can be taken from the corresponding component<P>
|
|
of another <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A>. When the two pathnames are for different<P>
|
|
file systems (in implementations that support multiple file<P>
|
|
systems), an appropriate translation occurs. If no meaningful<P>
|
|
translation is possible, an error is signalled. The definitions<P>
|
|
of "appropriate" and "meaningful" are implementation-dependent.<P>
|
|
<P>
|
|
f. When constructing a wildcard <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A>, the name, type, or version<P>
|
|
can be :WILD, which matches anything.<P>
|
|
<P>
|
|
g. An implementation might support other values for some components,<P>
|
|
but a portable program cannot use those values. A conforming program<P>
|
|
can use implementation-dependent values but this can make it<P>
|
|
non-portable, for example, it might work only with Unix file systems.<P>
|
|
<P>
|
|
<B>Consequences:<P>
|
|
</B><P>
|
|
The changes relative to CLtL plus <A HREF="iss266.htm">PATHNAME-UNSPECIFIC-COMPONENT</A><P>
|
|
are as follows:<P>
|
|
<P>
|
|
The removal of punctuation characters during parsing is specified.<P>
|
|
<P>
|
|
"Structured" components are disallowed in non-wildcard pathnames,<P>
|
|
except for the specific structuring of directories specified<P>
|
|
in issue <A HREF="iss263.htm">PATHNAME-SUBDIRECTORY-LIST</A>.<P>
|
|
<P>
|
|
"Structured" hosts are allowed, a generalization of CLtL's list<P>
|
|
of strings.<P>
|
|
<P>
|
|
The type and version can be "structured" in wildcard pathnames.<P>
|
|
<P>
|
|
The difference between what component values a program can depend<P>
|
|
on being able to use, versus what component values a program must<P>
|
|
be prepared to encounter, is clarified.<P>
|
|
<P>
|
|
The implementation-dependent variations are identified explicitly.<P>
|
|
<P>
|
|
<B>Rationale:<P>
|
|
</B> <P>
|
|
This should make it easier to write portable programs that deal with<P>
|
|
pathnames and make it easier for implementors by clarifying the<P>
|
|
framework into which they must fit. Also it should make it easier<P>
|
|
to write the Common Lisp language specification by resolving some<P>
|
|
things that were unclear about the status quo.<P>
|
|
<P>
|
|
Adding "structured" hosts conforms to current practice.<P>
|
|
<P>
|
|
Substituting a default host for <A REL=DEFINITION HREF="../Body/a_nil.htm#nil"><B>NIL</B></A> conforms to current practice<P>
|
|
in implementations that <A REL=DEFINITION HREF="../Body/f_provid.htm#require"><B>require</B></A> all pathnames to have a specific host.<P>
|
|
<P>
|
|
Confining "structured" devices and names to wildcard pathnames, and<P>
|
|
replacing "structured" directories with an explicit specification of<P>
|
|
the form of the directory value, should improve portability without causing<P>
|
|
any harm.<P>
|
|
<P>
|
|
:WILD is only required to be supported in the name, type, or version,<P>
|
|
which are the easiest to implement and the most useful in applications.<P>
|
|
<P>
|
|
<B>Current practice:<P>
|
|
</B> <P>
|
|
All versions of Symbolics Genera violate CLtL in the matter of hosts,<P>
|
|
since it uses standard-objects as the host component. Genera deviates<P>
|
|
slightly from <A HREF="iss263.htm">PATHNAME-SUBDIRECTORY-LIST</A>, but otherwise conforms to<P>
|
|
<A HREF="iss257.htm">PATHNAME-COMPONENT-VALUE:SPECIFY</A>.<P>
|
|
<P>
|
|
Like Genera, the Explorer current practice is to use an object instead of<P>
|
|
a string for the host component. The directory component is a list of<P>
|
|
strings, not yet supporting the symbols specified in proposal<P>
|
|
PATHNAME-SUBDIRECTORY-LIST; other than that, the Explorer conforms to<P>
|
|
proposal <A HREF="iss257.htm">PATHNAME-COMPONENT-VALUE:SPECIFY</A>.<P>
|
|
<P>
|
|
Macintosh Allegro Common Lisp 1.2.2 uses <A REL=DEFINITION HREF="../Body/a_nil.htm#nil"><B>NIL</B></A> and "" for :UNSPECIFIC,<P>
|
|
and uses a string with punctuation characters instead of a list for<P>
|
|
the directory. <A REL=DEFINITION HREF="../Body/f_mk_pn.htm#make-pathname"><B>MAKE-PATHNAME</B></A> won't set a component to <A REL=DEFINITION HREF="../Body/a_nil.htm#nil"><B>NIL</B></A> when<P>
|
|
:DEFAULTS is used, it merges with the defaults instead.<P>
|
|
Otherwise it seems consistent with what is proposed.<P>
|
|
<P>
|
|
Lucid Common Lisp 3.0.1 under Unix uses <A REL=DEFINITION HREF="../Body/a_nil.htm#nil"><B>NIL</B></A> for :UNSPECIFIC, and uses<P>
|
|
a list for directories of somewhat different form from what is proposed<P>
|
|
in <A HREF="iss263.htm">PATHNAME-SUBDIRECTORY-LIST</A>. Lucid lets you store arbitrary information<P>
|
|
in the version field with <A REL=DEFINITION HREF="../Body/f_mk_pn.htm#make-pathname"><B>MAKE-PATHNAME</B></A> :VERSION and will return it with<P>
|
|
<A REL=DEFINITION HREF="../Body/f_pn_hos.htm#pathname-version"><B>PATHNAME-VERSION</B></A> (as long as it's a symbol or an integer), even though<P>
|
|
it's not used. Otherwise it seems consistent with what is proposed.<P>
|
|
<P>
|
|
Ibuki Common Lisp Release 01/01 behaves the same as Lucid, including the<P>
|
|
same form of structured directory, except it doesn't have the ability to<P>
|
|
store information in the unused <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A> version field, and it has the<P>
|
|
same bug in <A REL=DEFINITION HREF="../Body/f_mk_pn.htm#make-pathname"><B>MAKE-PATHNAME</B></A> that the Macintosh has. Otherwise it seems<P>
|
|
consistent with what is proposed.<P>
|
|
<P>
|
|
Other implementations were not surveyed.<P>
|
|
<P>
|
|
This proposal assumes that no current or planned implementation<P>
|
|
uses "structured" names except possibly for wildcards.<P>
|
|
<P>
|
|
<B>Cost to Implementors:<P>
|
|
</B><P>
|
|
Most implementations already conform, except for the changes required<P>
|
|
by <A HREF="iss266.htm">PATHNAME-UNSPECIFIC-COMPONENT</A> and <A HREF="iss263.htm">PATHNAME-SUBDIRECTORY-LIST</A>, so<P>
|
|
the cost of this proposal itself should be minimal. It is conceivable<P>
|
|
that an implementation may exist that has to change its <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A><P>
|
|
representation, for example one that uses numbers as "structured" devices.<P>
|
|
Some implementations may have to change their treatment of punctuation<P>
|
|
characters.<P>
|
|
<P>
|
|
<B>Cost to Users:<P>
|
|
</B><P>
|
|
None.<P>
|
|
<P>
|
|
<B>Cost of non-adoption:<P>
|
|
</B> <P>
|
|
Pathnames will continue to be a poorly specified part of the language.<P>
|
|
<P>
|
|
<B>Performance impact:<P>
|
|
</B><P>
|
|
None of any significance.<P>
|
|
<P>
|
|
<B>Benefits/Esthetics:<P>
|
|
</B><P>
|
|
The boundary between the specified behavior of pathnames and the<P>
|
|
implementation-dependent behavior of pathnames will be more clear.<P>
|
|
<P>
|
|
<B>Discussion:<P>
|
|
</B><P>
|
|
Sandra Loosemore comments:<P>
|
|
<P>
|
|
As I've said before, I don't think that trying to construct or pick<P>
|
|
apart pathnames by component can be accomplished portably in any case,<P>
|
|
because even if you restrict the representation of what can appear in<P>
|
|
the various components, the objects you stuff in may or may not make<P>
|
|
sense for a particular file system. Instead, I would much prefer to<P>
|
|
deprecate <A REL=DEFINITION HREF="../Body/f_mk_pn.htm#make-pathname"><B>MAKE-PATHNAME</B></A> and the PATHNAME-xxx accessors and leave the<P>
|
|
question of representation of components unspecified in the <A REL=DEFINITION HREF="../Body/07_ffb.htm#standard"><B>standard</B></A>.<P>
|
|
<P>
|
|
I realize that this position may be seen as being too extreme. In<P>
|
|
that case I'd be willing to shut up and go along with proposal SPECIFY<P>
|
|
as long as my position gets noted in the writeup.<P>
|
|
<P>
|
|
Larry Masinter and Dave Moon both feel that we should be able to<P>
|
|
prescribe exact <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A> component values for popular file systems, so<P>
|
|
that multiple implementations will behave the same way when using the<P>
|
|
same file system. Obvious candidates as the key file systems are MS/DOS,<P>
|
|
Macintosh, Unix, and VAX/VMS. A call for volunteers to write up tables<P>
|
|
for any of them produced absolutely no response, however.<P>
|
|
</PRE>
|
|
<HR>
|
|
|
|
<A REL=NAVIGATOR HREF="../Front/StartPts.htm"><IMG WIDTH=80 HEIGHT=40 ALT="[Starting Points]" SRC="../Graphics/StartPts.gif" ALIGN=Bottom></A><A REL=TOC HREF="../Front/Contents.htm"><IMG WIDTH=80 HEIGHT=40 ALT="[Contents]" SRC="../Graphics/Contents.gif" ALIGN=Bottom></A><A REL=INDEX HREF="../Front/X_Master.htm"><IMG WIDTH=80 HEIGHT=40 ALT="[Index]" SRC="../Graphics/Index.gif" ALIGN=Bottom></A><A REL=INDEX HREF="../Front/X_Symbol.htm"><IMG WIDTH=80 HEIGHT=40 ALT="[Symbols]" SRC="../Graphics/Symbols.gif" ALIGN=Bottom></A><A REL=GLOSSARY HREF="../Body/26_a.htm"><IMG WIDTH=80 HEIGHT=40 ALT="[Glossary]" SRC="../Graphics/Glossary.gif" ALIGN=Bottom></A><A HREF="../Front/X3J13Iss.htm"><IMG WIDTH=80 HEIGHT=40 ALT="[Issues]" SRC="../Graphics/Issues.gif" ALIGN=Bottom></A><BR>
|
|
|
|
<A REL=COPYRIGHT HREF="../Front/Help.htm#Legal"><I>Copyright 1996-2005, LispWorks Ltd. All rights reserved.</I></A><P>
|
|
</BODY>
|
|
</HTML>
|