[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: Pathname-subdirectory-list
- To: Masinter.pa@Xerox.COM, Ghenis.pasa@Xerox.COM
- Subject: Issue: Pathname-subdirectory-list
- From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Thu, 16 Jul 87 20:14 EDT
- Cc: cl-cleanup@sail.stanford.edu
- In-reply-to: <870715-132705-3165@Xerox>
- Line-fold: No
Date: 15 Jul 87 13:24 PDT
From: Masinter.pa@Xerox.COM
PROBLEM DESCRIPTION:
It is impossible to write PORTABLE code that can produce a pathname
based on directory plus SUBDIRECTORY information. If the directory used
is not a root, then the string provided must contain OS-specific
separators. This defeats the purpose of having an abstraction like
pathname. Specifying a subdirectory RELATIVE to the current default is
possible but also inconvenient and non-portable.
This problem is even worse for programs running on machines on a network
that can retrieve files from multiple hosts, each using a different OS
and thus a different subdirectory delimiter.
I agree with the problem description. We've been dealing with heterogeneous
network for quite some time and have run into the same thing.
PROPOSAL (PATHNAME-SUBDIRECTORY-LIST:ALLOW):
Add a :SUBDIRECTORIES field to pathnames, to store a list of strings.
Adding a new field as a way of solving this problem doesn't make sense.
Subdirectories are a structuring of the existing directory field, they are
not a new -independent- aspect of a pathname.
The solution to this problem that Symbolics has used for years works
quite well. The directory is a structured field whose value is returned
as a list of strings, one string for each subdirectory level. In
addition to strings, in our system we allow certain keywords in the
list, enumerated below. Note that this general approach is the solution
suggested by CLtL itself, page 412 about 3/4 of the way down the page;
thus the only reason to change the language would be if we want to force
all implementations to use the same representation of structured
directories, which might be difficult if some implementation uses a
strange file system with a directory feature we haven't thought of.
When constructing a pathname, either a list of strings, or a single
string containing host-dependent delimiters, is accepted. To retrieve a
string containing host-dependent delimiters, the existing
DIRECTORY-NAMESTRING function is used.
In case those keywords aren't self-evident, here are some examples.
Vixen is a Unix, presumably everyone is familiar with Unix pathname
syntax.
(make-pathname :host "vixen"
:directory '("foo" "bar")) => #P"VIXEN:/foo/bar/"
(make-pathname :host "vixen"
:directory '(:relative "bar")) => #P"VIXEN:bar/"
(make-pathname :host "vixen"
:directory '(:relative :up "bar")) => #P"VIXEN:../bar/"
(make-pathname :host "vixen"
:directory '(:relative :up :up "bar")) => #P"VIXEN:../../bar/"
(make-pathname :host "vixen"
:directory '("foo" :wild "bar")) => #P"VIXEN:/foo/*/bar/"
I can't show you :wild-inferiors on Unix, because Unix is too simple
and elegant to have such useful features, so I'll use VMS:
(make-pathname :host "dumbo"
:directory '("foo" :wild "bar")) => #P"DUMBO:[foo.*.bar]"
(make-pathname :host "dumbo"
:directory '("foo" :wild-inferiors "bar")) => #P"DUMBO:[foo...bar]"
The name of the VMS host is not intended to be particularly pejorative, all of our
Vaxes are named after flying critters.