Andreas Franke <afranke@...> writes:
> Suppose you have the following three files:
> touch /tmp/tmp.foo
> touch /tmp/tmp.bar.bar
> touch /tmp/tmpbaz
> How can I find the same files as
> ls /tmp/tmp*
> On pretty much every lisp except SBCL,
> (directory "/tmp/tmp*")
> returns all three of the above files, but SBCL only finds
> "/tmp/tmpbaz". (Tested on SBCL 1.0.7 on Linux.) Is this a feature
> or a bug?
It doesn't sound like a bug to me. What you need to understand is that
unlike Unix filenames CL pathnames are structured data. SBCL maps your
test cases (+ an additional relevant one) as follows:
1. tmp.foo -> :name "tmp" :type "foo"
2. tmp.bar.baz -> :name "tmp.bar" :type "baz"
3. tmpbaz -> :name "tmpbaz" :type nil
4. tmpbah. -> :name "tmpbaz" :type ""
Now, DIRECTORY is supposed to return the existing files whose
pathnames match the pathname deisgnator given as argument. The
relevant cases are:
A. *.* -> :name :wild :type :wild
B. * -> :name :wild :type nil
C. *. -> :name :wild :type ""
It seems obvious to me that given those structured representations,
pathname A should match all cases 1-4, B should match only pathname 3,
and C should match only pathname 4. Of course the standard doesn't
specify what matching actually means, so I'm sure that you could come
up with elaborate and spec-compliant ideas like treating a nil type as
a wild type iff the name is also wild, or something. But doing that
just to cover up one mismatch between the unix model (filenames are a
bunch of octets) and the CL model doesn't sound like a good idea.
Also note that on most Lisps it's actually impossible to find the same
files as "ls /tmp/foo*", since DIRECTORY must do truename
canonicalization, which is generally considered to imply symlink
resolution. If you really want Unix filesystem semantics, you need to
call the appropriate posix routines with FFI.