From: Andreas F. <af...@ag...> - 2007-09-28 17:43:40
|
Hello. 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* does? 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? Even if I don't need tmpbaz, I cannot use "/tmp/tmp.*" because it will miss tmp.bar.bar. On the other hand, "/tmp/tmp*.*" will include tmpbaz on most lisps, but not on clisp. My workaround so far is to use "/tmp/tmp*" with an extra ".*" appended in case of #+SBCL. Is there a better solution? Thanks, Andreas |
From: <kn...@on...> - 2007-10-02 09:36:39
|
Andreas Franke wrote: > Hello. > > 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* > does? > I did (directory "*.*") and it worked.. A quick look at sbcl/src/code/filesys.lisp makes me think that the directory function could use som help. > 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? > > Even if I don't need tmpbaz, I cannot use > "/tmp/tmp.*" because it will miss tmp.bar.bar. > On the other hand, "/tmp/tmp*.*" will include > tmpbaz on most lisps, but not on clisp. > > My workaround so far is to use "/tmp/tmp*" > with an extra ".*" appended in case of #+SBCL. > Is there a better solution? > > Thanks, > Andreas > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Sbcl-devel mailing list > Sbc...@li... > https://lists.sourceforge.net/lists/listinfo/sbcl-devel > > -- Free Software Consultant Cell: +47 - 47 34 40 08 Phone: +47 - 21 53 69 00, Fax: +47 - 21 53 69 09 Addr: Slemdalsveien 70, PB 1 Vinderen, 0319 Oslo <http://www.freecode.no/> |
From: Juho S. <js...@ik...> - 2007-10-02 11:13:49
|
Andreas Franke <af...@ag...> writes: > Hello. > > 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* > does? > > 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. -- Juho Snellman |
From: Andreas F. <af...@ag...> - 2007-10-03 03:44:10
|
Thanks for your hints and explanation, Christophe, Knut Olav and Juho! Now I feel a lot more comfortable with this formerly pretty scary topic... Best, Andreas |