Next: Operations on Pathnames, Previous: Filenames and Pathnames, Up: Pathnames
A pathname object always has six components, described below. These components are the common interface that allows programs to work the same way with different file systems; the mapping of the pathname components into the concepts peculiar to each file system is taken care of by the Scheme implementation.
#f
or the value of the variable
local-host
.
Note that a pathname is not necessarily the name of a specific file.
Rather, it is a specification (possibly only a partial specification) of
how to access a file. A pathname need not correspond to any file that
actually exists, and more than one pathname can refer to the same file.
For example, the pathname with a version of newest
may refer to
the same file as a pathname with the same components except a certain
number as the version. Indeed, a pathname with version newest
may refer to different files as time passes, because the meaning of such
a pathname depends on the state of the file system. In file systems
with such facilities as “links”, multiple file names, logical devices,
and so on, two pathnames that look quite different may turn out to
address the same file. To access a file given a pathname, one must do a
file-system operation such as open-input-file
.
Two important operations involving pathnames are parsing and merging. Parsing is the conversion of a filename (which might be something supplied interactively by the users when asked to supply the name of a file) into a pathname object. This operation is implementation-dependent, because the format of filenames is implementation-dependent. Merging takes a pathname with missing components and supplies values for those components from a source of default values.
Not all of the components of a pathname need to be specified. If a
component of a pathname is missing, its value is #f
.
Before the file system interface can do anything interesting with a
file, such as opening the file, all the missing components of a pathname
must be filled in. Pathnames with missing components are used
internally for various purposes; in particular, parsing a namestring
that does not specify certain components will result in a pathname with
missing components.
Any component of a pathname may be the symbol unspecific
, meaning
that the component simply does not exist, for file systems in which such
a value makes no sense. For example, unix and Windows file
systems usually do not support version numbers, so the version component
for such a host might be unspecific
.1
In addition to #f
and unspecific
, the components of a
pathname may take on the following meaningful values:
host?
predicate.
absolute
or the symbol
relative
. If the first element in the list is the symbol
absolute
, then the directory component (and subsequently the
pathname) is absolute; the first component in the sequence is to
be found at the “root” of the file system. If the directory is
relative then the first component is to be found in some as yet
unspecified directory; typically this is later specified to be the
current working directory.
Aside from absolute
and relative
, which may only appear as
the first element of the list, each subsequent element in the list is
either: a string, which is a literal component; the symbol wild
,
meaningful only when used in conjunction with the directory reader; or
the symbol up
, meaning the next directory is the “parent” of
the previous one. up
corresponds to the file .. in unix
and PC file systems.
(The following note does not refer to any file system currently
supported by MIT/GNU Scheme, but is included for completeness.) In file
systems that do not have “hierarchical” structure, a specified
directory component will always be a list whose first element is
absolute
. If the system does not support directories other than
a single global directory, the list will have no other elements. If the
system supports “flat” directories, i.e. a global set of directories
with no subdirectories, then the list will contain a second element,
which is either a string or wild
. In other words, a
non-hierarchical file system is treated as if it were hierarchical, but
the hierarchical features are unused. This representation is somewhat
inconvenient for such file systems, but it discourages programmers from
making code depend on the lack of a file hierarchy.
wild
,
meaningful only when used in conjunction with the directory reader.
wild
,
meaningful only when used in conjunction with the directory reader.
newest
, which means to choose the largest available version
number for that file; the symbol oldest
, which means to choose
the smallest version number; or the symbol wild
, meaningful only
when used in conjunction with the directory reader. In the future some
other possible values may be added, e.g. installed
. Note that
currently no file systems support version numbers; thus this component
is not used and should be specified as #f
.
Returns a pathname object whose components are the respective arguments. Each argument must satisfy the restrictions for the corresponding component, which were outlined above.
(make-pathname #f #f '(absolute "usr" "morris") "foo" "scm" #f) => #[pathname 67 "/usr/morris/foo.scm"]
Returns a particular component of pathname.
(define x (->pathname "/usr/morris/foo.scm")) (pathname-host x) => #[host 1] (pathname-device x) => unspecific (pathname-directory x) => (absolute "usr" "morris") (pathname-name x) => "foo" (pathname-type x) => "scm" (pathname-version x) => unspecific
Returns a new copy of pathname with the respective component replaced by the second argument. Pathname is unchanged. Portable programs should not explicitly replace a component with
unspecific
because this might not be permitted in some situations.(define p (->pathname "/usr/blisp/rel15")) p => #[pathname 71 "/usr/blisp/rel15"] (pathname-new-name p "rel100") => #[pathname 72 "/usr/blisp/rel100"] (pathname-new-directory p '(relative "test" "morris")) => #[pathname 73 "test/morris/rel15"] p => #[pathname 71 "/usr/blisp/rel15"]
These operations are similar to the
pathname-new-
component operations, except that they only change the specified component if it has the value#f
in pathname.
[1] This description is adapted from Common Lisp, The Language, second edition, section 23.1.1.