2 @comment node-name, next, previous, up
11 @comment node-name, next, previous, up
12 @section Lisp Pathnames
14 There are many aspects of ANSI Common Lisp's pathname support which are
15 implementation-defined and so need documentation.
17 @c FIXME: as a matter of ANSI conformance, we are required to document
18 @c implementation-defined stuff, which for pathnames (chapter 19 of CLtS)
21 @c * Otherwise, the parsing of thing is implementation-defined.
24 @c * If thing contains an explicit host name and no explicit device name,
25 @c then it is implementation-defined whether parse-namestring will supply
26 @c the standard default device for that host as the device component of
27 @c the resulting pathname. (PARSE-NAMESTRING)
29 @c * The specific nature of the search is implementation-defined.
30 @c (LOAD-LOGICAL-PATHNAME-TRANSLATIONS)
32 @c * Any additional elements are implementation-defined.
33 @c (LOGICAL-PATHNAME-TRANSLATIONS)
35 @c * The matching rules are implementation-defined but should be consistent
36 @c with directory. (PATHNAME-MATCH-P)
38 @c * Any such additional translations are implementation-defined.
39 @c (TRANSLATE-LOGICAL-PATHNAMES)
41 @c * ...or an implementation-defined portion of a component...
42 @c (TRANSLATE-PATHNAME)
44 @c * The portion of source that is copied into the resulting pathname is
45 @c implementation-defined. (TRANSLATE-PATHNAME)
47 @c * During the copying of a portion of source into the resulting
48 @c pathname, additional implementation-defined translations of case or
49 @c file naming conventions might occur. (TRANSLATE-PATHNAME)
51 @c * In general, the syntax of namestrings involves the use of
52 @c implementation-defined conventions. (19.1.1)
54 @c * The nature of the mapping between structure imposed by pathnames and
55 @c the structure, if any, that is used by the underlying file system is
56 @c implementation-defined. (19.1.2)
58 @c * The mapping of the pathname components into the concepts peculiar to
59 @c each file system is implementation-defined. (19.1.2)
61 @c * Whether separator characters are permitted as part of a string in a
62 @c pathname component is implementation-defined; (19.2.2.1.1)
64 @c * Whether a value of :unspecific is permitted for any component on any
65 @c given file system accessible to the implementation is
66 @c implementation-defined. (19.2.2.2.3)
68 @c * Other symbols and integers have implementation-defined meaning.
71 @c * The existence and meaning of SYS: logical pathnames is
72 @c implementation-defined. (19.3.1.1.1)
74 @node Native Filenames
75 @comment node-name, next, previous, up
76 @section Native Filenames
78 In some circumstances, what is wanted is a Lisp pathname object which
79 corresponds to a string produced by the Operating System. In this case,
80 some of the default parsing rules are inappropriate: most filesystems do
81 not have a native understanding of wild pathnames; such functionality is
82 often provided by shells above the OS, often in mutually-incompatible
85 To allow the user to deal with this, the following functions are
86 provided: @code{parse-native-namestring} and @code{native-pathname}
87 return the closest equivalent Lisp pathname to a given string
88 (appropriate for the Operating System), while @code{native-namestring}
89 converts a non-wild pathname designator to the equivalent native
90 namestring, if possible. Some Lisp pathname concepts (such as the
91 @code{:back} directory component) have no direct equivalents in most
92 Operating Systems; the behaviour of @code{native-namestring} is
93 unspecified if an inappropriate pathname designator is passed to it.
95 @include fun-sb-ext-parse-native-namestring.texinfo
96 @include fun-sb-ext-native-pathname.texinfo
97 @include fun-sb-ext-native-namestring.texinfo