Re: [Sbcl-devel] DIRECTORY weirdness

[William H. N. <wil...@ai...>]

On Tue, Jan 01, 2002 at 02:15:32AM +0000, Daniel Barlow wrote:
> William Harold Newman <wil...@ai...> writes:
> 
> > Currently,
> >   (a) (PATHNAME "/usr/bin") gives you a different result than 
> >       (PATHNAME "/usr/bin/").
> >   (b) (DIRECTORY "/usr/*.*") gives you an entry for "/usr/bin" which
> >       is of the (PATHNAME "/usr/bin/") type.
> > 
> > I think (a) is probably the right behavior, or at least I can't see
> > how to avoid it. However, I'm a little skeptical about (b). It seems
> > strange for a pathname returned by (DIRECTORY "/usr/*.*") to have an
> > empty PATHNAME-NAME part, and a PATHNAME-DIRECTORY part which doesn't
> > match (PATHNAME-DIRECTORY "/usr/").
> 
> Strange maybe, but it's a whole lot more useful than "/usr/bin" would
> be.  I would tend to work on the basis that DIRECTORY should probably
> only list objects that actually exist, and there is no file called
> "bin" in there, whereas there is a directory.

I'm not sure that the current behavior is more useful unless the
programmer abandons the idea of a portable filesystem abstraction and
knows that it's Unix-y underneath, and furthermore knows that we've
made this arbitrary choice of mapping from Unix to Common Lisp. There
doesn't seem to be any really right way to make the Unix idea that
directories are files visible through the Common Lisp abstraction. As
far as I can tell, portable code can't assume that a file with empty
PATHNAME-NAME is a directory. There could easily be some other
filesystem out there which represented something completely different
with empty PATHNAME-NAME values.

> The other possibility is for DIRECTORY not to list subdirectories at
> all, and expect people to use recursive wildcards if they want to
> descend the tree.  But that would suck too, being either slow or
> nonterminating on very big or circular trees.

As I see it, the reason we should show Unix directory files in
DIRECTORY output is for the same reason that we decided that other
Unix quasi-file objects like dangling soft links should show up even
though you can't do anything useful with them: at least you should be
able to tell they're there so you understand why you can't delete the
enclosing directory, or create another file with the same name, or
whatever. In that spirit, I'm inclined to change the values returned
by DIRECTORY from the CMU CL style to the (PATHNAME "/usr/bin") style.

I agree that this won't be good for dealing with really big Unix
directory trees, but my feeling is that the Common Lisp pathname
system to deal with this is not the right way to try to deal with the
general problem of exploring Unix filesystems anyway. If someone wants
to get serious about exploring Unix filesystems, it'd probably be
better to make a set of bindings to the Unix calls, and then convert
into PATHNAMEs only at the last minute before doing Lisp i/o. Otherwise,
directory files and really big filesystems are the least of their
problems, since they'll also get hit by soft links and hard links
and devices and pipes and who knows what.

Any code which tried to make use of the CMU-CL-style mapping of Unix
directory files onto files with empty PATHNAME-NAME would have to be
#+(OR SBCL CMU) anyway. Thus, IMHO, it might as well just break down
and use the FFI to make Unix system calls, or at least use a higher
level but still Unix-aware, usable-on-SBCL-and-CMU-CL library
implemented in terms of the FFI.

If we go the other way, of trying to extend SBCL's implementation of
Common Lisp pathnames to deal with Unixisms, I think the CL pathname
system will get unmanageably baroque long before we have an
industrial-strength solution suitable for interacting with huge
arbitrary Unix filesystems.

-- 
William Harold Newman <wil...@ai...>
HAPPY HACKING TO ALL, AND I'LL BE BACK NEXT YEAR!
  -- http://www.yetanother.org/damian/diary_December_2001.html#day_24
PGP key fingerprint 85 CE 1C BA 79 8D 51 8C  B9 25 FB EE E0 C3 E5 7C