[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Issue: PATHNAME-WILD (version 5)

>   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,

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.
>     :PATHNAME-MATCH messages resemble TRANSLATE-PATHNAME and

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

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