| Previous Section | Next Section | Table of Contents | Glossary | Index |
Leading tilde (~) characters in physical pathname namestrings are expanded in the way that most shells do:
"~user/..." can be used to refer to an absolute pathname rooted
at the home directory of the user named "user".
"~/..." can be used to refer to an absolute pathname rooted at
the home directory of the current user.
Clozure CL sets up logical pathname translations for logical hosts: ccl and home
The CCL logical host should point to the
ccl directory. It is used for a variety of
purposes by Clozure CL including: locating Clozure CL source code,
require and provide, accessing
foreign function information, and the Clozure CL build process. It
is set to the value of the environment variable
CCL_DEFAULT_DIRECTORY, which is set by the
openmcl shell script Section 2.3.1, “The ccl Shell Script”. If
CCL_DEFAULT_DIRECTORY is not set, then it is set
to the directory containing the current heap image.
The syntax of namestrings is implementation-defined in Common Lisp. Portable programs cannot assume much of anything about them. (See section 19.1.1 of the Common Lisp standard for more information.)
When translating a namestring into a pathname object, most
implementations seem to follow the convention that a dot
character in the namestring separates the
pathname-name and
the pathname-type. When there is more
than one dot in involved, or when dots appear at the beginning
or end of the namestrings, what to do is less clear: does
".emacs" describe a pathname whose name is
nil and whose type is emacs
or something else? Similarly, given "a.b.c", the question
is which parts are parsed as the pathname name, and which are
parsed as the pathname type?
When generating a namestring from a pathname object (as happens, for example, when printing a pathname), Clozure CL tries to avoid some potential ambiguity by escaping characters that might otherwise be used to separate pathname components. The character used to quote or escape the separators is a backlash on Unix systems, and a #\> character on Windows. So, for example, "a\\.b.c" has name "a.b" and type "c", whereas "a.b\\.c" has name "a" and type "b.c".
To get a native namestring suitable for passing to an
operating system command, use the function
ccl:native-translated-namestring.
This function returns a namestring that represents a pathname using the native conventions of the operating system. Any quoting or escaping of special characters will be removed.
For example, suppose that p is a pathname made
by (make-pathname :name "a.b" :type "c").
Then, (native-translated-namestring p) evaluates
to "a.b.c". By contrast, (namestring p) evaluates
to "a\\.b.c".
Executes forms in an environemt in which each var is bound to a stack-allocated foreign pointer which refers to a C-style string suitable for passing to foreign code which expects a filename argument.
For example, one might use this macro in the following way:
(with-filename-cstrs ((s (native-translated-namestring pathname))) (#_unlink s))
Various operating systems have different conventions for how they expect native pathname strings to be encoded. Darwin expects then to be decomposed UTF-8. The Unicode variants to Windows file-handling functions expect UTF-16. Other systems just treat them as opaque byte sequences. This macro ensures that the correct encoding is used, whatever the host operating system.
Pathname strings are treated as null-terminated strings coded in the encoding named by the value returned by the function CCL:PATHNAME-ENCODING-NAME. This value may be changed with SETF.
| Previous Section | Next Section | Table of Contents | Glossary | Index |