PATHNAME-TYPE-UNSPECIFICNIL, or :WILD.'' This description is too restrictive to be practical.
In file systems which have no first-class notion of a name/type distinction, it is possible to make files named "foo." and "foo" which are distinct. 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.
:UNSPECIFIC as a value of the type field of a pathname for operating systems in which it makes sense.
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.
:UNSPECIFIC makes sense...
(PATHNAME-TYPE (MAKE-PATHNAME :TYPE :UNSPECIFIC)) => :UNSPECIFIC
(PATHNAME-TYPE (MERGE-PATHNAMES (MAKE-PATHNAME :TYPE :UNSPECIFIC) (MAKE-PATHNAME :TYPE "FOO")))
:UNSPECIFIC on Unix and ITS file systems, for example.
Some implementations which use a non-standard token other than :UNSPECIFIC to implement this functionality might 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 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.'' TITAN TITAN P û/ãObú\ >/> zº*start* 01214 00024 US Return-Path: <CL-Cleanup-mailer@SAIL.Stanford.EDU> Redistributed: xerox-cl-cleanup^.pa Received: from SAIL.Stanford.EDU ([36.86.0.194]) by Xerox.COM ; 12 JAN 89 00:33:24 PST Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 12 Jan 89 00:33:05 PST Received: from Semillon.ms by ArpaGateway.ms ; 12 JAN 89 00:31:54 PST Date: 12 Jan 89 00:30 PST Sender: masinter.pa Subject: Issue: PATHNAME-TYPE-UNSPECIFIC (Version 1) To: cl-cleanup@sail.stanford.edu From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK> Message-ID: <890112-003154-11895@Xerox>
[lmm: from Ballot]
I can understand why someone might find the need for :UNSPECIFIC in Unix unclear, but I think that is because it is not clear what filenames would be parsed as pathnames with :UNSPECIFIC type [*]; :UNSPECIFIC is nonetheless useful for building pathnames directly when you know which case you want and need a way to specify it.
[*] Does a name without "." parse as type NIL or :UNSPECIFIC? Different Unix programs use different conventions. Some are willing to merge in a type field, others, such as the C compiler, leave names as-is. So the "right" answer may vary.