On 24 September 2014 08:59, Mark Evenson <
evenson@panix.com> wrote:
On 24 Sep 2014, at 06:05, Pascal J. Bourguignon <pjb@informatimago.com> wrote:
Why do we have?
(wild-pathname-p #P"*-blah") -> T
(wild-pathname-p #P"*-blah" :name) -> NIL
This is inconsistent (and non-conforming).
Looking at the java code, it seems a bit naive/lazy. The memq for the
directory does catch
directories like foo/bar/*/baz (which _are_ wild), but it also
seemingly catches other
cases like foo/bar/baz*baz/otherstuff. I'm not convinced this is
non-conforming, though,
since implementations are allowed to support implementation-dependent
strings that
contain wildcard characters, which is what we do.
Having said that, in such cases I usually prefer doing what sbcl does,
as far as possible. :)
I’m not sure this is advisable with respect to pathnames. sbcl is strongly influenced by cmucl, and cmucl is not the best implementation about pathnames, IMO.
That said, the wild-pathname-p implementation should rather be consensual, CLHS doesn’t seem to leave much to implementation choice in it.
Only, it shall depend on how the implementation supports wild components.
For logical pathnames, there are :wild components and wildcard-word (or also wild-inferior-words for directories) components (they must be both supported).
For physical pathnames, only :wild or :wild-inferiors components must be supported, but of course, it is highly advisable to document and support wildcards in physical components too.
And since we also want to support POSIX paths as physical pathnames, which may contain any sequence of byte, we want to distinguish physical pathname syntax, from plain POSIX paths.
(Let’s also keep in mind that POSIX paths may contain any control character and any sequence of byte that is *invalid* UTF-8 (apart from 0)).
I’m reminding all this, because foo/bar/baz*baz/otherstuff is ambiguous:
- it may be a physical pathname syntax with a wildcard-word component using a syntax similar to logical pathnames, ( #P"foo/bar/baz*baz/otherstuff” ), or
- it may be a native pathname string representation of the POSIX path #(102 111 111 47 98 97 114 47 98 97 122 42 98 97 122 47 111 116 104 101 114 115 116 117 102 102).
In the first case, it’d be a wild-pathname, in the later case, it wouldn’t be.