Hi!
On my laptop (Linux) I have a directory /tmp/bar/ which contains the
two files baz.txt and frob.txt. Three Lisps (AllegroCL 6.2 trial,
LispWorks 4.36, and CMUCL 18e) give this result:
* (pathname-match-p #p"/tmp/bar/baz.txt" #p"/tmp/bar/")
T
* (wild-pathname-p #p"/tmp/bar/")
NIL
* (directory #p"/tmp/bar/")
(#p"/tmp/bar/baz.txt" #p"/tmp/bar/frob.txt")
Two other Lisps (SBCL 0.8.6 and CLISP 2.32) give this result:
* (pathname-match-p #p"/tmp/bar/baz.txt" #p"/tmp/bar/")
T
* (wild-pathname-p #p"/tmp/bar/")
NIL
* (directory #p"/tmp/bar/")
(#P"/tmp/bar/")
I have to admit I'm confused by both.
The SBCL/CLISP way seems to contradict the dictionary entry for
PATHNAME-MATCH-P[1] which says that the "matching rules are
implementation-defined but should be consistent with DIRECTORY." OK,
it says "should" and not "must" but what's the use of PATHNAME-MATCH-P
if it's /not/ consistent with DIRECTORY?
The AllegroCL/LispWorks/CMUCL way seem to contradict the dictionary
entry for DIRECTORY[2] which says that "if the pathspec is not wild,
the resulting list will contain either zero or one elements." (The
only escape hatch I see is that one could argue that the spec doesn't
explicitely say that a pathname is wild if and only if WILD-PATHNAME-P
returns a true value for this pathname. However, especially in light
of the X3J13 Cleanup Issue PATHNAME-WILD:NEW-FUNCTIONS[3], it seems
clear to me that this is the /intention/ of WILD-PATHNAME-P.)
All five implementations actually confuse me because they all agree
that
(pathname-match-p #p"/tmp/bar/baz.txt" #p"/tmp/bar/")
results in a true value.[5] I'm not questioning whether this is ANSI
compliant ("the matching rules are implementation-defined", after all)
and I'm sure there must be a valid reason to do it like this if five
major CL implementations agree but I would have expected a NIL answer
because the second argument has NIL components but no :WILD
components. Hmm.... What am I missing?
Would someone please elucidate me?
Thanks in advance,
Edi.
PS: I'm pretty sure the answer is somewhere in the c.l.l archives but
cursory googling didn't yield any meaningful results.
PPS: In case you're wondering why I'm asking this: No, I'm not trying
to prove a point. I am, just for the fun of it, working on a
"portable" "directory walker" (where "portable" means "works on
the Unix/Linux, Windows, Mac OS implementations I know of"
because the file systems are rather similar and "directory
walker" is a function which recurses down a directory). I didn't
want to go the osicat[4] way (using the FFI) but instead wanted
to use implementation-specific facilities (like AllegroCL's
FILE-DIRECTORY-P) where necessary and portable code otherwise.
I'm beginning to think that this is actually impossible if the
resulting function is supposed to (a) be useful and (b) return
the same results on the same OS.
[1] <http://www.lispworks.com/reference/HyperSpec/Body/f_pn_mat.htm>
[2] <http://www.lispworks.com/reference/HyperSpec/Body/f_dir.htm>
[3] <http://www.lispworks.com/reference/HyperSpec/Issues/iss267_w.htm>
[4] <http://www.cliki.net/Osicat>
[5] A sixth implementation, ECL 0.9c, is with me here in that it
returns NIL, but it doesn't have WILD-PATHNAME-P and (DIRECTORY
#p"/tmp/bar/") returns both ".txt" files which is equally
inconsistent IMHO.
On Fri, 02 Jan 2004 23:54:05 +0100, I wrote:
> All five implementations actually confuse me because they all agree
> that
>
> (pathname-match-p #p"/tmp/bar/baz.txt" #p"/tmp/bar/")
>
> results in a true value.[5] I'm not questioning whether this is ANSI
> compliant ("the matching rules are implementation-defined", after
> all) and I'm sure there must be a valid reason to do it like this if
> five major CL implementations agree but I would have expected a NIL
> answer because the second argument has NIL components but no :WILD
> components. Hmm.... What am I missing?
As James Anderson pointd out to me in private email:
From <http://www.lispworks.com/reference/HyperSpec/Body/f_pn_mat.htm>:
"Missing components of wildcard default to :WILD."
It looks like no matter how often I read a CLHS entry I always manage
to miss the one important sentence... :(
However, my other questions are still open (at least for me).
Cheers,
Edi.