Previous Section Next Section Table of Contents Glossary Index

Chapter 4. Using Clozure CL

4.6. Pathnames

4.6.1. Pathname Expansion

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.

4.6.2. Predefined Logical Hosts

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.

4.6.3. Pathname Namestrings

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. Working with native namestrings


native-translated-namestring pathname-designator
Return a namestring that uses the conventions of the native operating system.


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".


with-filename-cstrs ( {(var value)}* ) {form}*
Suitably encode strings to be used as filenames for foreign code.


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.

4.6.4. OS X (Darwin)

Clozure CL assumes that pathname strings are decomposed UTF-8.

4.6.5. Linux

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.

4.6.6. FreeBSD

Pathname strings are treated as null-terminated strings encoded according to the current locale; a future release may change this convention to use UTF-8.

Previous Section Next Section Table of Contents Glossary Index