Issue: PATHNAME-SUBDIRECTORY-LIST (Version 2)

[Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>]

    Date: 7 Jul 88 16:09:32 EDT (Thu)
    From: gz@spt.entity.com (Gail Zacharias)

       Date: Tue, 5 Jul 88 14:56 EDT
       From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>

	 (PATHNAME-DIRECTORY (PARSE-NAMESTRING ">foo>*>bar>baz.lisp")) ;on LispM
	 => (:ABSOLUTE "FOO" :WILD "BAR")

    I think this is pointless.  Why should there be special syntax for "*" but
    not for "x*z"?  It only gives you the ability to detect a small subset of
    possible wildcard specs, and it only gives you the ability to construct
    a small subset of wildcard specs (and there's nothing equivalent for even
    this small subset within file names or types or devices).  It's a hack, which
    might get in the way of a more general solution.  Why not just leave everything
    as strings for now, and leave other data types for any possible less ad hoc
    approaches to the wildcard issues.

I'm not sure of this myself, but I've not studied the issue well enough.
Anyway, it is already institutionalized in that CL already permits :WILD
as a filler of a directory slot even though there might be internal star
matches.

I think the main intent is to allow a person to write a portable call
like (DIRECTORY (MAKE-PATHNAME :NAME "FOO" :TYPE :WILD :VERSION :WILD))
without worrying that "*" might not be the wildcard char in all systems.

It just occurred to me that you are (and I was) supposing that "*" is
what :WILD translates to, but in fact it might not be. I guess I think
it's defensible (albeit less elegant) to support this particular special
case because it does have broader application in portable programs.

Btw, even systems which support embedded "*" disagree as to its
treatment. In some (eg, ITS) the * matches exactly one char, while in
others (eg, Unix or Lispm), it matches any number of chars.
Interestingly, ITS agrees however that when "*" stands alone that it
matches a variable number of chars...