[Openmcl-devel] DIRECTORY quibbles
Erik Pearson
erik at defunweb.com
Wed May 16 10:26:58 PDT 2012
I was tinkering with DIRECTORY, attempting to debug something with ASDF.
I discovered that (DIRECTORY "*") was returning directories in the current
working directory, but not directories with dots in their names.
Reading the CCL docs http://ccl.clozure.com/manual/chapter4.4.html (also
the docs included in trunk), the interface specifies a keyword option
:DIRECTORIES which should default to NIL. It is apparently defaulting to T,
and checking the source files it is coded this way. I think the
documentation specifies the correct, or at least most conforming, behavior,
that is, to list files. Maybe it is less surprising to get directories by
default, by analogy to an OS level directory listing command like ls or dir.
However, I find it odd that specifying a file wildcard matches on
directories. For instance (DIRECTORY (MAKE-PATHNAME :DIRECTORY NIL :NAME
:WILD :TYPE :WILD) :DIRECTORIES T :FILES NIL) will return all directories.
I would expect this to always return NIL. I'm asking for just directories
which have a any filename, any type, and no directory.
I would expect (DIRECTORY (MAKE-PATHNAME :DIRECTORY '(:RELATIVE :WILD))
:DIRECTORIES T :FILES NIL) to return all directories in the current working
directory, and it does. I'm asking for just directories, relative to the
current working directory, with a any directory name.
The converse works as expected: (DIRECTORY (MAKE-PATHNAME :DIRECTORY
'(:RELATIVE :WILD)) :DIRECTORIES NIL :FILES T) returns NIL.
I really don't see the need for :DIRECTORIES or :FILES at all if DIRECTORY
follows the pathname object for matching.
In fact, CLISP implements DIRECTORY in this very manner. It doesn't have
keyword options to specify wither files or directories are requested --
rather it uses the pathname spec. (DIRECTORY #P"*/") returns all
directories, (DIRECTORY "*.*") returns all files and no directories.
Finally, DIRECTORY has an undocumented keyword option :TEST which would be
super handy if it is in an appropriate state for public consumption.
Maybe I'm barking up the wrong tree?
Thanks,
Erik.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20120516/87be7900/attachment.htm>
More information about the Openmcl-devel
mailing list