PATHNAME-UNSPECIFIC-COMPONENT- Unix pathnames never have a version field.
- In some file systems, specifying a device and a directory means something very different than specifying the device alone, particularly when the device is a "logical device" that may already imply a directory.
- Some Unix pathnames have types and others do not. For example, it is possible to make files named "foo." and "foo" which are distinct. CLtL (p412) specifies that the type is ``always a string, NIL, or :WILD.'' This description is too restrictive to be practical in this case. One of these (usually the former) can get a type of "" but it is not clear how to represent the other. If NIL is used, merging primitives cannot detect that the field is filled and should not be merged against.
- ITS pathnames have either a version or a type, but never both. "JOE;FILE 32" has a directory, a name, and a version. "JOE;FILE TEXT" has a directory, a name, and a type. "JOE;FILE TEXT 32" is not a possible ITS filename.
:UNSPECIFIC as a value of any field of a pathname, including the HOST, DEVICE, DIRECTORY, NAME, TYPE, or VERSION field of a pathname, for file systems in which it makes sense.
The results of supplying :UNSPECIFIC to a file system for which it does not make sense are undefined.
When a pathname is converted to a namestring, NIL and :UNSPECIFIC are treated as if the field were empty. That is, they both cause the component not to appear in the string.
When merging, however, only a NIL value for a component will be replaced with the default for that component, while :UNSPECIFIC will be left alone as if the field were filled.
Portable programs should expect to find :UNSPECIFIC in the device, directory, type, or version field in some implementations.
Portable programs should not explicitly place :UNSPECIFIC in any field, since that it might not be permitted in some situations, but portable programs may sometimes do so implicitly.
;; #1: Non-portable code. This may signal an error in some ;; implementations where an unspecific type makes no sense.
(MAKE-PATHNAME :TYPE :UNSPECIFIC) ;not portable
;; #2: In this example, assume a Unix file system.
(PATHNAME-TYPE (PARSE-NAMESTRING "foo.")) => ""
(PATHNAME-TYPE (PARSE-NAMESTRING "foo")) => :UNSPECIFIC
(PATHNAME-TYPE (MERGE-PATHNAMES (PARSE-NAMESTRING "foo") (MAKE-PATHNAME :TYPE "BAR"))) => :UNSPECIFIC
;; #3: In this example, assume an ITS file system.
(LET ((P (PARSE-NAMESTRING "FOO 32")))
(LIST (PATHNAME-TYPE P) (PATHNAME-VERSION P)))
=> (:UNSPECIFIC 32)
(LET ((P (PARSE-NAMESTRING "FOO TEXT")))
(LIST (PATHNAME-TYPE P) (PATHNAME-VERSION P)))
=> ("TEXT" :UNSPECIFIC)
(LET ((P (MERGE-PATHNAMES (PARSE-NAMESTRING "FOO 32")
(PARSE-NAMESTRING "FOO TEXT"))))
(LIST (PATHNAME-TYPE P) (PATHNAME-VERSION P)))
=> (:UNSPECIFIC 32)
;; Note: It is not the intent of this proposal to actually legislate ;; the canonical representation of Unix pathnames "foo." and "foo", ;; nor of ITS pathnames "FOO 32" and "FOO TEXT". That should probably ;; be done, but under separate cover. The above examples are intended ;; only to demonstrate how this proposal will permit the representation ;; of pathnames not usefully representable under CLtL.
:UNSPECIFIC on Unix and ITS file systems, for example.Some implementations which already do this are legitimized.
Some implementations which use a non-standard token other than :UNSPECIFIC to implement this functionality would want to switch to use :UNSPECIFIC so that portable programs could expect it.
:UNSPECIFIC in the type fields in some situations.
Any program which doesn't already expect :UNSPECIFIC is already not really portable, however, given that some implementations have been forced to go beyond the standard in order to represent all possible pathnames.
CL model and reality.PATHNAME-TYPE-UNSPECIFIC:NEW-TOKEN.
This feature existed (for types) in the Colander draft edition of CLtL, but was removed for the Laser edition. The following text is excerpted from the Colander edition, p259:
``??? Query: Is :unspecific really needed over and above nil?
``A component of a pathname can also be the keyword :UNSPECIFIC. This means that the component has been explicitly determined not to be there, as opposed to be missing. One way this can occur is with generic pathnames, which refer not to a file but to a whole family of files. The version, and usually the type, of a generic pathname are :unspecific. Another way :unspecific is used to represent components that are not simply supported by a file system. When a pathname is converted to a namestring, nil and :unspecific both cause the component not to appear in the string. When merging, however, a nil value for a component will be replaced with the default for that component, while :unspecific will be left alone.''
"The stuff about generic pathnames in the discussion section was brain damage and may have lead to the confusion that caused :unspecific to be dropped from Common Lisp. Only the stuff about components not supported by a file system makes sense."
----- End Forwarded Messages -----