[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: email@example.com
- Subject: MERGE-PATHNAMES-DIRECTORY:EXTEND
- From: firstname.lastname@example.org (Aaron Larson)
- Date: Sat, 4 Mar 89 13:18:42 CST
- Posted-date: Sat, 4 Mar 89 13:18:42 CST
I understand that there may be a proposal that deals with this topic under
discussion in Cleanup, if so I'm willing to retract this submission.
References: MERGE-PATHNAMES (p415), MAKE-PATHNAME (p416),
PATHNAME-DIRECTORY (p417), DIRECTORY-NAMESTRING (p417)
Edit history: 03-Mar-89, Version 1 by ALarson
Merging of pathname components currently only supports complete
replacement. While this is satisfactory for "simple" components such as
type and version, the directory component on most modern operating systems
must describe a hierarchical directory structure and as such could benefit
from a more sophisticated merging policy.
For example; many large software packages exist in a collection of
directories that are related in a specific way starting at an arbitrary
location in the directory hierarchy (e.g. the FOO package may be
structured with ....foo/src, ....foo/bin, ....foo/doc, etc. where "...."
is some arbitrary directory path). The current specification of
MERGE-PATHNAMES does not permit the two parts of the directory component
to be specified separately in an implementation independent manner such
that MERGE-PATHNAMES could construct the entire directory path.
Introduce the concept of an "absolute" pathname and a "relative" pathname.
An absolute pathname is one that starts at the beginning (or top) of the
host file system, a relative pathname is one which starts at an
unspecified location. A relative pathname must be merged with a absolute
pathname before it can be used to reference a file.
Specify that when the PATHNAME (first) argument to MERGE-PATHNAMES is a
relative pathname, the directory component of the DEFAULTS (second)
argument will appear first in the directory component of the resulting
pathname, followed by the directory component of the PATHNAME argument.
If the PATHNAME argument is an absolute pathname, then the directory
component of the resulting pathname will be the same as the directory
component of the PATHNAME argument.
The value specified for the :DIRECTORY keyword may be a list of keywords
and strings that denote the directory components in the directory path.
If the list begins with the keyword :ABSOLUTE the resulting pathname is
absolute, if the list begins with the keyword :RELATIVE then the
resulting pathname is relative. The results are implementation defined
if the list does not begin with one the keywords :RELATIVE or :ABSOLUTE.
In addition to :ABSOLUTE and :RELATIVE, an implementation may permit
additional keywords to appear in the directory list. The following
keywords, if they are accepted will have the following meaning; :WILD
matches all directories at the given location in the directory path, :UP
specifies that when MERGE-PATHNAMES is applied, one directory will be
eliminated from the resulting directory path, and :WILD-INFERIORS
which matches all directories below the point at which the
:WILD-INFERIORS keyword appears in the directory path.
<<< There should be a way to deal with UNIX style pathnames where
:UP is not strictly syntactic (i.e. it may depend on the file system.
A keyword dealing with this sort of thing would have to be maintained
until TRUENAME was gotten. I don't have a good candidate name for it
Introduce a new function;
Path should be pathname, PATHNAME-ABSOLUTE-P returns true if path is an
absolute pathname, and false otherwise.
Specify that PATHNAME-DIRECTORY returns a list of the directory
componentsfor the given pathname. If pathname is an absolute pathname,
then the CAR of the list will be :ABSOLUTE, otherwise it will be
:RELATIVE. The results are undefined if the return value is modified.
(setq abs-1 (MAKE-PATHNAME :DIRECTORY '(:ABSOLUTE "a")))
(setq abs-2 (MAKE-PATHNAME :DIRECTORY '(:ABSOLUTE "b")))
(setq rel-1 (MAKE-PATHNAME :DIRECTORY '(:RELATIVE "c")))
(setq rel-2 (MAKE-PATHNAME :DIRECTORY '(:RELATIVE "d"")))
(PATHNAME-DIRECTORY (MERGE-PATHNAMES abs-1 abs-2)) => (:ABSOLUTE "a")
(PATHNAME-DIRECTORY (MERGE-PATHNAMES abs-1 rel-1)) => (:ABSOLUTE "a")
(PATHNAME-DIRECTORY (MERGE-PATHNAMES rel-1 abs-1)) => (:ABSOLUTE "a" "c")
(PATHNAME-DIRECTORY (MERGE-PATHNAMES rel-1 rel-2)) => (:RELATIVE "d" "c")
(NOT (PATHNAME-ABSOLUTE-P abs-1)) => NIL
(PATHNAME-ABSOLUTE-P rel-1) => NIL
Allegro ExCL uses the same representations as descrived in this proposal,
and lucid and Symbolics Genera (presumably TI lispm as well) are very
close. Allegro CL and Symbolics Genera 7.2 already perform merging as
described in this proposal (which is clearly not legal CLtL). KCL, VAXLISP
2.1 and LUCID v?? do pathname directory merging as described in CLtL.
Symbolics Genera, LUCID, KCL, and Allegro already return lists from
PATHNAME-DIRECTORY, VAXLISP returns a string. Symbolics Genera currently
does pathname canonicalization for components specified in calls to
make-pathname, and reverses the canonicalization in the pathname-*
functions, but the intermediate pathname has the case of the components
inverted (at least for BSD 4.2 style pathnames).
KCL (unix) (:ROOT . strings) (strings)
Franz Allegro (unix) (:ABSOLUTE . strings) (:RELATIVE . strings)
Symbolics (lispm) (strings) (:RELATIVE . strings)
Lucid (unix) (strings) (:RELATIVE . strings)
Cost to Implementors:
Unknown, but not likely to be excessive.
Cost to Users:
Minimal. This is an imcompatible change in that pathname merging will no
longer always en mass replace the directory component, however portable
programs can currently only be using absolute pathnames whose behaviour
remans unchanged. The return value of PATHNAME-DIRECTORY is undefined now,
this proposal would make it defined. Although this could break existing
programs, they are already not portable.
Cost of non-adoption:
Manipulation of structured directory components will continue to be
Manipulating structured directory components will be easier, and the
pathname functions will more accurately model existing file system