334 lines
22 KiB
HTML
334 lines
22 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-SUBDIRECTORY-LIST 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/iss261_w.htm">
|
|
<LINK REL=UP HREF="../Issues/iss263.htm">
|
|
<LINK REL=NEXT HREF="../Issues/iss264_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/iss261_w.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Previous]" SRC="../Graphics/Prev.gif" ALIGN=Bottom></A><A REL=UP HREF="../Issues/iss263.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Up]" SRC="../Graphics/Up.gif" ALIGN=Bottom></A><A REL=NEXT HREF="../Issues/iss264_w.htm"><IMG WIDTH=40 HEIGHT=40 ALT="[Next]" SRC="../Graphics/Next.gif" ALIGN=Bottom></A></H1>
|
|
|
|
<HR>
|
|
|
|
|
|
|
|
<H2>Issue PATHNAME-SUBDIRECTORY-LIST Writeup</H2>
|
|
|
|
<PRE><B>Status:</B> passed, as amended, Jun 89 X3J13<P>
|
|
<B>Issue:</B> <A HREF="iss263.htm">PATHNAME-SUBDIRECTORY-LIST</A><P>
|
|
<B>References:</B> Pathnames (pp410-413), <A REL=DEFINITION HREF="../Body/f_mk_pn.htm#make-pathname"><B>MAKE-PATHNAME</B></A> (p416),<P>
|
|
<A REL=DEFINITION HREF="../Body/f_pn_hos.htm#pathname-directory"><B>PATHNAME-DIRECTORY</B></A> (p417)<P>
|
|
Related-issues: <A HREF="iss256.htm">PATHNAME-COMPONENT-CASE</A>, <A HREF="iss257.htm">PATHNAME-COMPONENT-VALUE</A><P>
|
|
<B>Category:</B> CHANGE<P>
|
|
<B>Edit history:</B> 18-Jun-87, Version 1 by Ghenis.pasa@Xerox.COM<P>
|
|
05-Jul-88, Version 2 by Pitman (major revision)<P>
|
|
28-Dec-88, Version 3 by Pitman (merge discussion)<P>
|
|
22-Mar-89, Version 4 by Moon (fix based on discussion)<P>
|
|
19-May-89, Version 5 by Moon (improve based on mail)<P>
|
|
21-May-89, Version 6 by Moon (final cleanups)<P>
|
|
17-Jun-89, Version 7 by Moon (add current practice<P>
|
|
and discussion; minor fixes based on discussion)<P>
|
|
2-Jul-89, Version 8 by Masinter (add Jun89X3J13 amendment)<P>
|
|
<P>
|
|
<B>Problem Description:<P>
|
|
</B><P>
|
|
It is impossible to write portable code that can produce a <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A><P>
|
|
in a subdirectory of a hierarchical file system. This defeats much of<P>
|
|
the purpose of the <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A> abstraction.<P>
|
|
<P>
|
|
According to CLtL, only a string is a portable value for the directory<P>
|
|
component of a <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A>. Thus in order to denote a subdirectory, the use<P>
|
|
of punctuation characters (such as dots, slashes, or backslashes) would<P>
|
|
be necessary. The very fact that such syntax varies from host to host<P>
|
|
means that although the representation might be "portable", the code<P>
|
|
using that representation is not portable.<P>
|
|
<P>
|
|
This problem is even worse for programs running on machines on a network<P>
|
|
that can retrieve files from multiple hosts, each using a different OS<P>
|
|
and thus different subdirectory punctuation.<P>
|
|
<P>
|
|
Related problems:<P>
|
|
<P>
|
|
- In some implementations "FOO.BAR" might denote the "BAR" subdirectory<P>
|
|
of "FOO", while in other implementations it would denote a top-level<P>
|
|
directory, because "." is not treated as punctuation. To be safe,<P>
|
|
portable programs must avoid all potential punctuation characters.<P>
|
|
<P>
|
|
- Even in implementations where "." is used for subdirectories,<P>
|
|
"FOO.BAR" may be recognized by some to mean the "BAR" subdirectory of<P>
|
|
"FOO" and by others to mean `a seven character directory name with "."<P>
|
|
as the fourth character.'<P>
|
|
<P>
|
|
- In fact, CLtL does not even say whether punctuation characters are<P>
|
|
part of the string. eg, is "foo" or "/foo" the directory component for<P>
|
|
a unix <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A> "/foo/bar.lisp". Similarly, is "[FOO]" or "FOO" the<P>
|
|
directory component for a VMS <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A> "[FOO]ME.LSP"?<P>
|
|
<A HREF="iss257.htm">PATHNAME-COMPONENT-VALUE:SPECIFY</A> says punctuation characters are not<P>
|
|
part of the string.<P>
|
|
<P>
|
|
Proposal (<A HREF="iss263.htm">PATHNAME-SUBDIRECTORY-LIST:NEW-REPRESENTATION</A>)<P>
|
|
<P>
|
|
Remove the "structured" directory feature mentioned on CLtL p.412.<P>
|
|
<P>
|
|
Allow the value of a <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A>'s directory component to be a list. The<P>
|
|
<A REL=DEFINITION HREF="../Body/f_car_c.htm#car"><B>car</B></A> of the list is one of the symbols :ABSOLUTE or :RELATIVE.<P>
|
|
Each remaining element of the list is a string or a symbol (see below).<P>
|
|
Each string names a single level of directory <A REL=DEFINITION HREF="../Body/f_docume.htm#structure"><B>structure</B></A>. The strings<P>
|
|
should contain only the directory names themselves -- no punctuation<P>
|
|
characters.<P>
|
|
<P>
|
|
A list whose <A REL=DEFINITION HREF="../Body/f_car_c.htm#car"><B>car</B></A> is the symbol :ABSOLUTE represents a directory path<P>
|
|
starting from the root directory. The list (:ABSOLUTE) represents<P>
|
|
the root directory. The list (:ABSOLUTE "foo" "bar" "baz") represents<P>
|
|
the directory called "/foo/bar/baz" in Unix [except possibly for<P>
|
|
alphabetic case -- that is the subject of a separate issue].<P>
|
|
<P>
|
|
A list whose <A REL=DEFINITION HREF="../Body/f_car_c.htm#car"><B>car</B></A> is the symbol :RELATIVE represents a directory path<P>
|
|
starting from a default directory. The list (:RELATIVE) has the same<P>
|
|
meaning as <A REL=DEFINITION HREF="../Body/a_nil.htm#nil"><B>NIL</B></A> and hence is not used. The list (:RELATIVE "foo" "bar")<P>
|
|
represents the directory named "bar" in the directory named "foo" in the<P>
|
|
default directory.<P>
|
|
<P>
|
|
In place of a string, at any point in the list, symbols may occur to<P>
|
|
indicate special file notations. The following symbols have <A REL=DEFINITION HREF="../Body/07_ffb.htm#standard"><B>standard</B></A><P>
|
|
meanings. Implementations are permitted to add additional objects of any<P>
|
|
non-string type if necessary to represent features of their file systems<P>
|
|
that cannot be represented with the <A REL=DEFINITION HREF="../Body/07_ffb.htm#standard"><B>standard</B></A> strings and symbols.<P>
|
|
Supplying any non-string, including any of the symbols listed below, to a<P>
|
|
file system for which it does not make sense signals an error of type<P>
|
|
<A REL=DEFINITION HREF="../Body/e_file_e.htm#file-error"><B>FILE-ERROR</B></A>. For example, Unix does not support :WILD-INFERIORS in<P>
|
|
most implementations.<P>
|
|
<P>
|
|
:WILD - Wildcard match of one level of directory <A REL=DEFINITION HREF="../Body/f_docume.htm#structure"><B>structure</B></A>.<P>
|
|
:WILD-INFERIORS - Wildcard match of any number of directory levels.<P>
|
|
:UP - Go upward in directory <A REL=DEFINITION HREF="../Body/f_docume.htm#structure"><B>structure</B></A> (semantic).<P>
|
|
:BACK - Go upward in directory <A REL=DEFINITION HREF="../Body/f_docume.htm#structure"><B>structure</B></A> (syntactic).<P>
|
|
<P>
|
|
:ABSOLUTE or :WILD-INFERIORS immediately followed by :UP or :BACK<P>
|
|
signals an error.<P>
|
|
<P>
|
|
"Syntactic" means that the action of :BACK depends only on the <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A><P>
|
|
and not on the contents of the file system. "Semantic" means that the<P>
|
|
action of :UP depends on the contents of the file system; to resolve<P>
|
|
a <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A> containing :UP to a <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A> whose directory component<P>
|
|
contains only :ABSOLUTE and strings requires probing the file system.<P>
|
|
:UP differs from :BACK only in file systems that support multiple<P>
|
|
names for directories, perhaps via symbolic links. For example,<P>
|
|
suppose that there is a directory<P>
|
|
(:ABSOLUTE "X" "Y" "Z")<P>
|
|
linked to <P>
|
|
(:ABSOLUTE "A" "B" "C")<P>
|
|
and there also exist directories<P>
|
|
(:ABSOLUTE "A" "B" "Q")<P>
|
|
(:ABSOLUTE "X" "Y" "Q")<P>
|
|
then<P>
|
|
(:ABSOLUTE "X" "Y" "Z" :UP "Q")<P>
|
|
designates<P>
|
|
(:ABSOLUTE "A" "B" "Q")<P>
|
|
while<P>
|
|
(:ABSOLUTE "X" "Y" "Z" :BACK "Q")<P>
|
|
designates<P>
|
|
(:ABSOLUTE "X" "Y" "Q")<P>
|
|
<P>
|
|
If a string is used as the value of the :DIRECTORY argument to<P>
|
|
<A REL=DEFINITION HREF="../Body/f_mk_pn.htm#make-pathname"><B>MAKE-PATHNAME</B></A>, it should be the name of a toplevel directory and should<P>
|
|
not contain any punctuation characters. Specifying a string, str, is<P>
|
|
equivalent to specifying the list (:ABSOLUTE str). Specifying the symbol<P>
|
|
:WILD is equivalent to specifying the list (:ABSOLUTE :WILD-INFERIORS),<P>
|
|
or (:ABSOLUTE :WILD) in a file system that does not support :WILD-INFERIORS.<P>
|
|
<P>
|
|
The <A REL=DEFINITION HREF="../Body/f_pn_hos.htm#pathname-directory"><B>PATHNAME-DIRECTORY</B></A> function always returns <A REL=DEFINITION HREF="../Body/a_nil.htm#nil"><B>NIL</B></A>, :UNSPECIFIC, or a<P>
|
|
list, never a string, never :WILD.<P>
|
|
<P>
|
|
The list returned is not guaranteed to be "freshly consed" -- the<P>
|
|
consequences of modifying this list is undefined.<P>
|
|
<P>
|
|
In non-hierarchical file systems, the only valid list values for the<P>
|
|
directory component of a <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A> are (:ABSOLUTE string) and<P>
|
|
(:ABSOLUTE :WILD). :RELATIVE directories and the keywords<P>
|
|
:WILD-INFERIORS, :UP, and :BACK are not used in non-hierarchical file<P>
|
|
systems.<P>
|
|
<P>
|
|
Pathname merging treats a relative directory specially. Let<P>
|
|
<pathname> and <defaults> be the first two arguments to<P>
|
|
<A REL=DEFINITION HREF="../Body/f_merge_.htm#merge-pathnames"><B>MERGE-PATHNAMES</B></A>. If (<A REL=DEFINITION HREF="../Body/f_pn_hos.htm#pathname-directory"><B>PATHNAME-DIRECTORY</B></A> <pathname>) is a list whose<P>
|
|
<A REL=DEFINITION HREF="../Body/f_car_c.htm#car"><B>car</B></A> is :RELATIVE, and (<A REL=DEFINITION HREF="../Body/f_pn_hos.htm#pathname-directory"><B>PATHNAME-DIRECTORY</B></A> <defaults>) is a list, then<P>
|
|
the merged directory is the value of<P>
|
|
(<A REL=DEFINITION HREF="../Body/f_append.htm#append"><B>APPEND</B></A> (<A REL=DEFINITION HREF="../Body/f_pn_hos.htm#pathname-directory"><B>PATHNAME-DIRECTORY</B></A> <defaults>)<P>
|
|
(<A REL=DEFINITION HREF="../Body/f_car_c.htm#cdr"><B>CDR</B></A> ;remove :RELATIVE from <A REL=DEFINITION HREF="../Body/s_the.htm#the"><B>the</B></A> front<P>
|
|
(<A REL=DEFINITION HREF="../Body/f_pn_hos.htm#pathname-directory"><B>PATHNAME-DIRECTORY</B></A> <pathname>)))<P>
|
|
except that if the resulting list contains a string or :WILD immediately<P>
|
|
followed by :BACK, both of them are removed. This removal of redundant<P>
|
|
:BACKs is repeated as many times as possible.<P>
|
|
If (<A REL=DEFINITION HREF="../Body/f_pn_hos.htm#pathname-directory"><B>PATHNAME-DIRECTORY</B></A> <defaults>) is not a list or<P>
|
|
(<A REL=DEFINITION HREF="../Body/f_pn_hos.htm#pathname-directory"><B>PATHNAME-DIRECTORY</B></A> <pathname>) is not a list whose <A REL=DEFINITION HREF="../Body/f_car_c.htm#car"><B>car</B></A> is :RELATIVE, the<P>
|
|
merged directory is<P>
|
|
(<A REL=DEFINITION HREF="../Body/a_or.htm#or"><B>OR</B></A> (<A REL=DEFINITION HREF="../Body/f_pn_hos.htm#pathname-directory"><B>PATHNAME-DIRECTORY</B></A> <pathname>) (<A REL=DEFINITION HREF="../Body/f_pn_hos.htm#pathname-directory"><B>PATHNAME-DIRECTORY</B></A> <defaults>))<P>
|
|
<P>
|
|
A relative directory in the <A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A> argument to a function such as<P>
|
|
<A REL=DEFINITION HREF="../Body/f_open.htm#open"><B>OPEN</B></A> is merged with <A REL=DEFINITION HREF="../Body/v_defaul.htm#STdefault-pathname-defaultsST"><B>*DEFAULT-PATHNAME-DEFAULTS*</B></A> before accessing the<P>
|
|
file system.<P>
|
|
<P>
|
|
<B>Test Cases/Examples:<P>
|
|
</B><P>
|
|
(<A REL=DEFINITION HREF="../Body/f_pn_hos.htm#pathname-directory"><B>PATHNAME-DIRECTORY</B></A> (<A REL=DEFINITION HREF="../Body/f_pars_1.htm#parse-namestring"><B>PARSE-NAMESTRING</B></A> "[FOO.BAR]BAZ.LSP")) ;on VMS<P>
|
|
=> (:ABSOLUTE "FOO" "BAR")<P>
|
|
<P>
|
|
(<A REL=DEFINITION HREF="../Body/f_pn_hos.htm#pathname-directory"><B>PATHNAME-DIRECTORY</B></A> (<A REL=DEFINITION HREF="../Body/f_pars_1.htm#parse-namestring"><B>PARSE-NAMESTRING</B></A> "/foo/bar/baz.lisp")) ;on Unix<P>
|
|
=> (:ABSOLUTE "foo" "bar")<P>
|
|
or (:ABSOLUTE "FOO" "BAR")<P>
|
|
If <A HREF="iss256.htm">PATHNAME-COMPONENT-CASE:KEYWORD-ARGUMENT</A> passes with a default of<P>
|
|
:COMMON, the value is the second one shown.<P>
|
|
<P>
|
|
(<A REL=DEFINITION HREF="../Body/f_pn_hos.htm#pathname-directory"><B>PATHNAME-DIRECTORY</B></A> (<A REL=DEFINITION HREF="../Body/f_pars_1.htm#parse-namestring"><B>PARSE-NAMESTRING</B></A> "../baz.lisp")) ;on Unix<P>
|
|
=> (:RELATIVE :UP)<P>
|
|
<P>
|
|
(<A REL=DEFINITION HREF="../Body/f_pn_hos.htm#pathname-directory"><B>PATHNAME-DIRECTORY</B></A> (<A REL=DEFINITION HREF="../Body/f_pars_1.htm#parse-namestring"><B>PARSE-NAMESTRING</B></A> "/foo/bar/../mum/baz")) ;on Unix<P>
|
|
=> (:ABSOLUTE "foo" "bar" :UP "mum")<P>
|
|
<P>
|
|
(<A REL=DEFINITION HREF="../Body/f_pn_hos.htm#pathname-directory"><B>PATHNAME-DIRECTORY</B></A> (<A REL=DEFINITION HREF="../Body/f_pars_1.htm#parse-namestring"><B>PARSE-NAMESTRING</B></A> ">foo>**>bar>baz.lisp")) ;on LispM<P>
|
|
=> (:ABSOLUTE "FOO" :WILD-INFERIORS "BAR")<P>
|
|
<P>
|
|
(<A REL=DEFINITION HREF="../Body/f_pn_hos.htm#pathname-directory"><B>PATHNAME-DIRECTORY</B></A> (<A REL=DEFINITION HREF="../Body/f_pars_1.htm#parse-namestring"><B>PARSE-NAMESTRING</B></A> ">foo>*>bar>baz.lisp")) ;on LispM<P>
|
|
=> (:ABSOLUTE "FOO" :WILD "BAR")<P>
|
|
<P>
|
|
<B>Rationale:<P>
|
|
</B><P>
|
|
This would allow programs to deal usefully with hierarchical file<P>
|
|
systems, which are by far the most common file system type.<P>
|
|
This would allow a system construction utility that organizes programs<P>
|
|
by subdirectories to be portable to all implementations that have<P>
|
|
hierarchical file systems.<P>
|
|
<P>
|
|
Discussion indicated that "Implementations are permitted to add<P>
|
|
additional objects of any non-string type if necessary to represent<P>
|
|
features of their file systems that cannot be represented with the<P>
|
|
<A REL=DEFINITION HREF="../Body/07_ffb.htm#standard"><B>standard</B></A> strings and symbols" is a necessary escape hatch for things like<P>
|
|
home directories and fancy pattern matching. Implementations should<P>
|
|
limit their use of this loophole and use the <A REL=DEFINITION HREF="../Body/07_ffb.htm#standard"><B>standard</B></A> keyword symbols<P>
|
|
whenever that is possible.<P>
|
|
<P>
|
|
<B>Current Practice:<P>
|
|
</B><P>
|
|
Symbolics Genera implements something very similar to this. The main<P>
|
|
differences are:<P>
|
|
- In Genera, there is no :ABSOLUTE keyword at the head of the list.<P>
|
|
This has been shown to cause some problems in dealing with root<P>
|
|
directories. Genera represents the root directory by a keyword<P>
|
|
symbol (rather than a list) because the list representation <P>
|
|
was not adequately general.<P>
|
|
- Genera has no separate concepts of :UP and :BACK. Genera<P>
|
|
represents Unix ".." as :UP, but deals with :UP syntactically, not<P>
|
|
semantically.<P>
|
|
<P>
|
|
On the Explorer, the directory component is a list of strings, not yet<P>
|
|
supporting the symbols specified in proposal <A HREF="iss263.htm">PATHNAME-SUBDIRECTORY-LIST</A>.<P>
|
|
<P>
|
|
Macintosh Allegro Common Lisp 1.2.2 uses a string with punctuation<P>
|
|
characters instead of a list for the directory.<P>
|
|
<P>
|
|
Lucid Common Lisp 3.0.1 under Unix uses a list for directories of<P>
|
|
somewhat different form from what is proposed in<P>
|
|
<A HREF="iss263.htm">PATHNAME-SUBDIRECTORY-LIST</A>. It uses :ROOT instead of :ABSOLUTE and uses<P>
|
|
".." instead of :UP. It does use :RELATIVE.<P>
|
|
<P>
|
|
Ibuki Common Lisp Release 01/01 uses a list for directories of somewhat<P>
|
|
different form from what is proposed in <A HREF="iss263.htm">PATHNAME-SUBDIRECTORY-LIST</A>. It<P>
|
|
uses :ROOT instead of :ABSOLUTE, uses :PARENT instead of :UP, and omits<P>
|
|
the leading keyword instead of using :RELATIVE.<P>
|
|
<P>
|
|
IIM uses a list for directories of somewhat different form from what is<P>
|
|
proposed in <A HREF="iss263.htm">PATHNAME-SUBDIRECTORY-LIST</A>. It uses :ABSOLUTE-DIRECTORY<P>
|
|
instead of :ABSOLUTE, uses :SUPER-DIRECTORY instead of :BACK, and omits<P>
|
|
the leading keyword instead of using :RELATIVE.<P>
|
|
<P>
|
|
<B>Cost to Implementors:<P>
|
|
</B><P>
|
|
In principle, nothing about the implementation needs to change except<P>
|
|
the treatment of the directory component by <A REL=DEFINITION HREF="../Body/f_mk_pn.htm#make-pathname"><B>MAKE-PATHNAME</B></A> and<P>
|
|
<A REL=DEFINITION HREF="../Body/f_pn_hos.htm#pathname-directory"><B>PATHNAME-DIRECTORY</B></A>. The internal representation can otherwise be left<P>
|
|
as-is if necessary.<P>
|
|
<P>
|
|
Implementations such as Genera, Explorer, Lucid, Ibuki, and IIM that<P>
|
|
already have hierarchical directory handling will have to make an<P>
|
|
incompatible change to switch to what is proposed here.<P>
|
|
<P>
|
|
For implementations that choose to rationalize this representation<P>
|
|
throughout their internals and any other implementation-specific<P>
|
|
accessors, the cost will be necessarily higher.<P>
|
|
<P>
|
|
<B>Cost to Users:<P>
|
|
</B><P>
|
|
None for portable programs. This change is upward compatible with CLtL.<P>
|
|
Nonportable programs will have to be changed if they use implementation<P>
|
|
dependent hierarchical directory handling and the implementation<P>
|
|
removes support for that when it adds support for this proposal.<P>
|
|
<P>
|
|
<B>Cost of Non-Adoption:<P>
|
|
</B><P>
|
|
Serious portability problems would continue to occur. Programmers would be<P>
|
|
driven to the use of implementation-specific facilities because the need<P>
|
|
for this is frequently impossible to ignore.<P>
|
|
<P>
|
|
<B>Benefits:<P>
|
|
</B><P>
|
|
The serious costs of non-adoption would be avoided.<P>
|
|
<P>
|
|
<B>Aesthetics:<P>
|
|
</B><P>
|
|
This representation of hierarchical pathnames is easy to use and quite<P>
|
|
general. Users will probably see this as an improvement in the aesthetics.<P>
|
|
<P>
|
|
<B>Discussion:<P>
|
|
</B><P>
|
|
This issue was raised a while back but no one was fond of the particular<P>
|
|
proposal that was submitted. This is an attempt to revive the issue.<P>
|
|
<P>
|
|
The original proposal, to add a :SUBDIRECTORIES component to a<P>
|
|
<A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A>, was discarded because it imposed an unnatural distinction<P>
|
|
between a toplevel directory and its subdirectories. Pitman's guess is<P>
|
|
the the idea was to try to make it a compatible change, but since most<P>
|
|
programmers will probably want to change from implementation-specific<P>
|
|
primitives to portable ones anyway, that's probably not such a big<P>
|
|
deal. Also, there could have been some programs which thought the<P>
|
|
change was compatible and ended up ignoring important information (the<P>
|
|
:SUBDIRECTORIES component). Pitman thought it would be better if<P>
|
|
people just accepted the cost of an incompatible change in order to<P>
|
|
get something really pretty as a result.<P>
|
|
<P>
|
|
Some people feel it is unnecessary to standardize the format of<P>
|
|
<A REL=DEFINITION HREF="../Body/a_pn.htm#pathname"><B>pathname</B></A> components such as the directory.<P>
|
|
<P>
|
|
Moon doesn't like having both :UP and :BACK, but admits that some<P>
|
|
file systems do it one way and some do it the other. He still thinks<P>
|
|
it would be simpler if we got rid of :BACK and just had :UP.<P>
|
|
<P>
|
|
To keep it simple, we chose not to add to this issue the functions<P>
|
|
DIRECTORY-PATHNAME-AS-FILE and PATHNAME-AS-DIRECTORY, which convert<P>
|
|
the name of a directory from or to the directory component of a file<P>
|
|
inferior to that directory. This conversion is system-dependent, for<P>
|
|
example TOPS-20 appends a type field and Unix does not. Also in some<P>
|
|
systems the root directory has a name and in others it doesn't. Of<P>
|
|
course these functions signal an error in non-hierarchical file<P>
|
|
systems. Examples (for Unix, assuming #P print syntax for pathnames):<P>
|
|
(directory-pathname-as-file #P"/usr/bin/sh") => #P"/usr/bin"<P>
|
|
(pathname-as-directory #P"/usr/bin") => #P"/usr/bin"/<P>
|
|
These functions have not been proposed because they are mainly useful<P>
|
|
in conjunction with additional functions for manipulating directories<P>
|
|
(creating, expunging, setting access control) that have not been made<P>
|
|
available in Common Lisp.<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>
|