Re: Issue: PATHNAME-WILD (version 5)

[David N Gray <Gray@DSG.csc.ti.com>]

> Proposal (PATHNAME-WILD:NEW-FUNCTIONS):
> 
>   Introduce the following three functions:
> 
>     WILD-PATHNAME-P pathname &optional field-key
...
>     If a non-null <field-key> is provided, it must be one of :HOST, :DEVICE,
>     :DIRECTORY, :NAME, :TYPE, or :VERSION.

I was worried that permitting (WILD-PATHNAME-P <path> :HOST) implied
that the host component might be wild, which is impossible in our
implementation.  But I see that proposal
PATHNAME-COMPONENT-VALUE:SPECIFY clarifies that the standard does not
require support for wild hosts.  So you might want to mention here that
(WILD-PATHNAME-P <path> :HOST) is allowed just in case some
implementation might support wild hosts as an extension.

> Current Practice:
> 
>   Presumably no implementation supports the proposal exactly as stated.
>   Symbolics Genera has had similar features under different names for many
>   years:
> 
>     (SEND pathname :WILD-P) returns a value such as NIL, :NAME, :TYPE,
>     etc., indicating the first wild field.
> 
>     (SEND pathname :NAME-WILD-P), (SEND pathname :DIRECTORY-WILD-P),
>     etc. test individual fields.
> 
>     The :TRANSLATE-WILD-PATHNAME, :TRANSLATE-WILD-PATHNAME-REVERSIBLE, and
>     :PATHNAME-MATCH messages resemble TRANSLATE-PATHNAME and
>     PATHNAME-MATCH-P.

The Explorer also supports the messages :WILD-P (although it only
returns NIL or T), :NAME-WILD-P, etc., :TRANSLATE-WILD-PATHNAME, and
:PATHNAME-MATCH.

>   The clarification is current practice as far as the authors are aware.
>   If some implementations are found that specify a meaning for wildcard
>   pathnames as arguments to these functions, this proposal should be changed
>   to say that the consequences are unspecified rather than signalling an error.

The Explorer permits DELETE-FILE on a wild pathname, meaning to delete
all files that match.