From: Nathan F. <fr...@ro...> - 2001-12-28 06:42:13
|
In 0.pre7.85 and 0.pre7.94, the following seems very wrong: (directory #p"*") => nil This is in a directory with approximately 70 files in it. I would try to be more informative, but I'm not sure what else can be said. -Nathan |
From: William H. N. <wil...@ai...> - 2001-12-28 15:28:23
|
On Fri, Dec 28, 2001 at 01:38:32AM -0500, Nathan Froyd wrote: > In 0.pre7.85 and 0.pre7.94, the following seems very wrong: > > (directory #p"*") => nil > > This is in a directory with approximately 70 files in it. Some things about pathnames are strange and awkward, e.g. you probably want (DIRECTORY #P"*.*") instead of what you wrote. But that doesn't solve the problem, so I agree that it looks as though DIRECTORY is broken. It looks to me as though the fix might be to tweak DEFUN DIRECTORY so that the pathname used in MERGE-DEFAULTS takes its :DIRECTORY part from *DEFAULT-PATHNAME-DEFAULTS*, i.e. (MERGE-PATHNAMES PATHNAME (MAKE-PATHNAME :NAME :WILD :TYPE :WILD :VERSION :WILD :DIRECTORY (PATHNAME-DIRECTORY *DEFAULT-PATHNAME-DEFAULTS*))) Would anyone who understands ANSI pathnames better like to comment? -- 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 |
From: Christophe R. <cs...@ca...> - 2001-12-28 17:01:46
|
On Fri, Dec 28, 2001 at 09:17:23AM -0600, William Harold Newman wrote: > On Fri, Dec 28, 2001 at 01:38:32AM -0500, Nathan Froyd wrote: > > In 0.pre7.85 and 0.pre7.94, the following seems very wrong: > > > > (directory #p"*") => nil > > > > This is in a directory with approximately 70 files in it. > > Some things about pathnames are strange and awkward, e.g. you probably > want (DIRECTORY #P"*.*") instead of what you wrote. But that doesn't > solve the problem, so I agree that it looks as though DIRECTORY is > broken. > > It looks to me as though the fix might be to tweak DEFUN DIRECTORY > so that the pathname used in MERGE-DEFAULTS takes its :DIRECTORY > part from *DEFAULT-PATHNAME-DEFAULTS*, i.e. > (MERGE-PATHNAMES PATHNAME > (MAKE-PATHNAME > :NAME :WILD > :TYPE :WILD > :VERSION :WILD > :DIRECTORY (PATHNAME-DIRECTORY > *DEFAULT-PATHNAME-DEFAULTS*))) > Would anyone who understands ANSI pathnames better like to comment? I don't know that I "understand" ANSI pathnames better, but I think that this is acceptable behaviour according to the spec; where pathnames are used, if a slot has a value of NIL then the value from *d-p-d* should be taken. It's not quite that simple, and in this case I think that it's reasonable that :wild be the default for the name, type and version, but *d-p-d* is in at least some sense the same concept as the "current working directory", so yes, the above modification is reasonable. I think that it's mandated by 19.2.3 in the hyperspec, too. As a side note, I would expect (directory #p"*") to work in exactly the same fashion as (directory #p"*.*") on all systems, for roughly the same reason, unless *d-p-d* has non-NIL name, type or version. So maybe this means it actually ought to be: (merge-pathnames (merge-pathnames pathname *default-pathname-defaults*) (make-pathname :name :wild :type :wild :version :newest)) I think that this is what ANSI is after. Cheers, Christophe -- Jesus College, Cambridge, CB5 8BL +44 1223 510 299 http://www-jcsu.jesus.cam.ac.uk/~csr21/ (defun pling-dollar (str schar arg) (first (last +))) (make-dispatch-macro-character #\! t) (set-dispatch-macro-character #\! #\$ #'pling-dollar) |
From: Alexey D. <ade...@co...> - 2001-12-29 05:13:03
|
Christophe Rhodes <cs...@ca...> writes: > On Fri, Dec 28, 2001 at 09:17:23AM -0600, William Harold Newman wrote: > > On Fri, Dec 28, 2001 at 01:38:32AM -0500, Nathan Froyd wrote: > > > In 0.pre7.85 and 0.pre7.94, the following seems very wrong: > > > > > > (directory #p"*") => nil > > > > > > This is in a directory with approximately 70 files in it. > > > > Some things about pathnames are strange and awkward, e.g. you probably > > want (DIRECTORY #P"*.*") instead of what you wrote. But that doesn't > > solve the problem, so I agree that it looks as though DIRECTORY is > > broken. > > > > It looks to me as though the fix might be to tweak DEFUN DIRECTORY > > so that the pathname used in MERGE-DEFAULTS takes its :DIRECTORY > > part from *DEFAULT-PATHNAME-DEFAULTS*, i.e. > > (MERGE-PATHNAMES PATHNAME > > (MAKE-PATHNAME > > :NAME :WILD > > :TYPE :WILD > > :VERSION :WILD > > :DIRECTORY (PATHNAME-DIRECTORY > > *DEFAULT-PATHNAME-DEFAULTS*))) > > Would anyone who understands ANSI pathnames better like to comment? > > I don't know that I "understand" ANSI pathnames better, but I think > that this is acceptable behaviour according to the spec; where > pathnames are used, if a slot has a value of NIL then the value from > *d-p-d* should be taken. It's not quite that simple, and in this case > I think that it's reasonable that :wild be the default for the name, > type and version, but *d-p-d* is in at least some sense the same > concept as the "current working directory", so yes, the above > modification is reasonable. I think that it's mandated by 19.2.3 in > the hyperspec, too. What is 19.2.3? I can not find it. > As a side note, I would expect (directory #p"*") to work in exactly > the same fashion as (directory #p"*.*") on all systems, for roughly > the same reason, unless *d-p-d* has non-NIL name, type or version. So > maybe this means it actually ought to be: > > (merge-pathnames (merge-pathnames pathname *default-pathname-defaults*) ^^^^^^^^^^^^^^^^^^^^^^^^^^^ it can be omitted here > (make-pathname :name :wild > :type :wild > :version :newest)) > > I think that this is what ANSI is after. I.e. you offer to treat NIL in NAME and TYPE as :WILD? In this case WILD-PATHNAME-P should be patched. Regards, Alexey Dejneka -- Greenspun's Tenth Rule of Programming as a reclame of Fortran |
From: Christophe R. <cs...@ca...> - 2001-12-29 10:53:31
|
On Sat, Dec 29, 2001 at 08:19:57AM +0300, Alexey Dejneka wrote: > Christophe Rhodes <cs...@ca...> writes: > > > On Fri, Dec 28, 2001 at 09:17:23AM -0600, William Harold Newman wrote: > > > On Fri, Dec 28, 2001 at 01:38:32AM -0500, Nathan Froyd wrote: > > > > In 0.pre7.85 and 0.pre7.94, the following seems very wrong: > > > > > > > > (directory #p"*") => nil > > > > > > > > This is in a directory with approximately 70 files in it. > > > > > > Some things about pathnames are strange and awkward, e.g. you probably > > > want (DIRECTORY #P"*.*") instead of what you wrote. But that doesn't > > > solve the problem, so I agree that it looks as though DIRECTORY is > > > broken. > > > > > > It looks to me as though the fix might be to tweak DEFUN DIRECTORY > > > so that the pathname used in MERGE-DEFAULTS takes its :DIRECTORY > > > part from *DEFAULT-PATHNAME-DEFAULTS*, i.e. > > > (MERGE-PATHNAMES PATHNAME > > > (MAKE-PATHNAME > > > :NAME :WILD > > > :TYPE :WILD > > > :VERSION :WILD > > > :DIRECTORY (PATHNAME-DIRECTORY > > > *DEFAULT-PATHNAME-DEFAULTS*))) > > > Would anyone who understands ANSI pathnames better like to comment? > > > > I don't know that I "understand" ANSI pathnames better, but I think > > that this is acceptable behaviour according to the spec; where > > pathnames are used, if a slot has a value of NIL then the value from > > *d-p-d* should be taken. It's not quite that simple, and in this case > > I think that it's reasonable that :wild be the default for the name, > > type and version, but *d-p-d* is in at least some sense the same > > concept as the "current working directory", so yes, the above > > modification is reasonable. I think that it's mandated by 19.2.3 in > > the hyperspec, too. > > What is 19.2.3? I can not find it. http://www.xanalys.com/software_tools/reference/HyperSpec/Body/sec_19-2-3.html Specifically, """ Except as explicitly specified otherwise, for functions that manipulate or inquire about files in the file system, the pathname argument to such a function is merged with *default-pathname-defaults* before accessing the file system (as if by merge-pathnames). """ > > As a side note, I would expect (directory #p"*") to work in exactly > > the same fashion as (directory #p"*.*") on all systems, for roughly > > the same reason, unless *d-p-d* has non-NIL name, type or version. So > > maybe this means it actually ought to be: > > > > (merge-pathnames (merge-pathnames pathname *default-pathname-defaults*) > ^^^^^^^^^^^^^^^^^^^^^^^^^^^ > it can be omitted here Oh, I know :). I was just trying to be clear... > > (make-pathname :name :wild > > :type :wild > > :version :newest)) > > > > I think that this is what ANSI is after. > > I.e. you offer to treat NIL in NAME and TYPE as :WILD? In this case > WILD-PATHNAME-P should be patched. That's a good point, actually. I don't think, you see, that there is any way to distinguish between NIL as "this part has no type" and NIL as "this part is of as-yet-unspecified type". But note that this is what is in current (well, 0.pre7.97). You're right, it looks wrong, as with a directory "/foo/" containing files "bar" and "bar.lisp", we get (both currently and with the above proposed modification) * (directory "/foo/bar") -> (#p"/foo/bar" #p"/foo/bar.lisp") * (directory "/foo/") -> (#p"/foo/bar" #p"/foo/bar.lisp") * (wild-pathname-p "/foo/") -> NIL Where what I think are probably the ANSI-mandated answers are * (directory "/foo/bar") -> (#p"/foo/bar") * (directory "/foo/") -> (#p"/foo/") * (wild-pathname-p "/foo/") -> NIL In other words, get rid of the second (exterior) merge with ":wild"s; this may break (non-conforming) code that assumes that (directory "/foo/") will list the files in that directory, whereas the conforming code to do that would be (directory "/foo/*.*"). In other words, merge just with *d-p-d* is my revised advice. Cheers, Christophe -- Jesus College, Cambridge, CB5 8BL +44 1223 510 299 http://www-jcsu.jesus.cam.ac.uk/~csr21/ (defun pling-dollar (str schar arg) (first (last +))) (make-dispatch-macro-character #\! t) (set-dispatch-macro-character #\! #\$ #'pling-dollar) |
From: Christophe R. <cs...@ca...> - 2001-12-30 14:09:05
Attachments:
sbcl.patch
|
On Sat, Dec 29, 2001 at 10:53:10AM +0000, Christophe Rhodes wrote: > In other words, merge just with *d-p-d* is my revised advice. And in case no-one disagrees with me (!), here's a patch to do this: csr21@lambda:/home/csr21/misc-cvs/sbcl$ ls -a /tmp #foo.lisp# .esd/ mutt-lambda-7506-2 ./ .font-unix/ mutt-lambda-7506-3 .#mutt-lambda-7506-3@ .gdm_socket= orbit-csr21/ ../ .sawfish-csr21/ sbcl-0.6.13/ .ICE-unix/ bar sbcl_0.6.13-6.diff.gz@ .X0-lock bar.lisp sbcl_0.6.13-6.dsc@ .X11-unix/ foo.lisp sbcl_0.6.13.orig.tar.gz@ .X2-lock ilisp.clc.patch ssh-XXeIONBL/ csr21@lambda:/home/csr21/misc-cvs/sbcl$ sbcl # with the following patch * (directory "/tmp/") (#P"/tmp/") * (directory "/tmp") (#P"/tmp/") * (directory "/tmp/*") (#P"/tmp/.ICE-unix/" #P"/tmp/.X0-lock" #P"/tmp/.X11-unix/" #P"/tmp/.X2-lock" #P"/tmp/.esd/" #P"/tmp/.font-unix/" #P"/tmp/.gdm_socket" #P"/tmp/.sawfish-csr21/" #P"/tmp/bar" #P"/tmp/orbit-csr21/" #P"/tmp/ssh-XXeIONBL/") * (directory "/tmp/bar") (#P"/tmp/bar") * (directory "/tmp/bar.*") (#P"/tmp/bar" #P"/tmp/bar.lisp") * (directory "/tmp/*.*") debugger invoked on condition of type SIMPLE-ERROR: segmentation violation at #X400C0BFD Um. So this is a bit odd; it's trying to resolve the link to something on an automounted partition. Still, I'm 99.9999999% sure that this isn't caused by this patch :) Cheers, Christophe -- Jesus College, Cambridge, CB5 8BL +44 1223 510 299 http://www-jcsu.jesus.cam.ac.uk/~csr21/ (defun pling-dollar (str schar arg) (first (last +))) (make-dispatch-macro-character #\! t) (set-dispatch-macro-character #\! #\$ #'pling-dollar) |
From: William H. N. <wil...@ai...> - 2001-12-30 16:07:56
|
On Sun, Dec 30, 2001 at 02:08:43PM +0000, Christophe Rhodes wrote: > On Sat, Dec 29, 2001 at 10:53:10AM +0000, Christophe Rhodes wrote: > > In other words, merge just with *d-p-d* is my revised advice. > > And in case no-one disagrees with me (!), here's a patch to do this: Thank you, I've made that change in 0.pre7.107 (not checked in yet). I added an item in NEWS about the change in DIRECTORY's behavior for e.g. (DIRECTORY "/tmp/"). > (#P"/tmp/bar" #P"/tmp/bar.lisp") > * (directory "/tmp/*.*") > > debugger invoked on condition of type SIMPLE-ERROR: > segmentation violation at #X400C0BFD > > Um. So this is a bit odd; it's trying to resolve the link to something > on an automounted partition. Still, I'm 99.9999999% sure that this > isn't caused by this patch :) I don't have automounted partitions to try to test this, but I agree that the problem seems unlikely to be caused by the patch. -- 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 |
From: Christophe R. <cs...@ca...> - 2001-12-30 19:10:07
|
On Sun, Dec 30, 2001 at 09:57:39AM -0600, William Harold Newman wrote: > On Sun, Dec 30, 2001 at 02:08:43PM +0000, Christophe Rhodes wrote: > > * (directory "/tmp/*.*") > > > > debugger invoked on condition of type SIMPLE-ERROR: > > segmentation violation at #X400C0BFD > > > > Um. So this is a bit odd; it's trying to resolve the link to something > > on an automounted partition. Still, I'm 99.9999999% sure that this > > isn't caused by this patch :) > > I don't have automounted partitions to try to test this, but I agree > that the problem seems unlikely to be caused by the patch. I'll do some testing soonish to see what's going on there... Cheers, Christophe -- Jesus College, Cambridge, CB5 8BL +44 1223 510 299 http://www-jcsu.jesus.cam.ac.uk/~csr21/ (defun pling-dollar (str schar arg) (first (last +))) (make-dispatch-macro-character #\! t) (set-dispatch-macro-character #\! #\$ #'pling-dollar) |
From: William H. N. <wil...@ai...> - 2001-12-30 19:23:48
|
On Sun, Dec 30, 2001 at 09:57:39AM -0600, William Harold Newman wrote: > On Sun, Dec 30, 2001 at 02:08:43PM +0000, Christophe Rhodes wrote: > > On Sat, Dec 29, 2001 at 10:53:10AM +0000, Christophe Rhodes wrote: > > > In other words, merge just with *d-p-d* is my revised advice. > > > > And in case no-one disagrees with me (!), here's a patch to do this: > > Thank you, I've made that change in 0.pre7.107 (not checked in yet). I > added an item in NEWS about the change in DIRECTORY's behavior for > e.g. (DIRECTORY "/tmp/"). However, once I tried to run the regression tests on 0.pre7.107, I found that the patch makes them fail, so I removed it. My guess is that the problem is not so much that the patch is wrong, as that it interacts badly with some implicit assumptions in %ENUMERATE-DIRECTORIES. %ENUMERATE-DIRECTORIES tries to maintain a running list (called NODES) of inodes (I think) that it has already seen, and check for membership in this list to avoid visiting any inode more than once. With the patch, somehow this goes astray. Thus when filesys.pure.lisp tests (DIRECTORY "../**/*.*") it doesn't find any of the files in the current working directory. %ENUMERATE-DIRECTORIES is rather convoluted, and I didn't happen to see an easy fix to make things work, so I just removed the patch for now, recording the original (DIRECTORY #P"*.*") problem as bug #139. -- 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 |
From: Christophe R. <cs...@ca...> - 2001-12-31 12:49:15
Attachments:
sbcl.patch
|
On Sun, Dec 30, 2001 at 01:13:31PM -0600, William Harold Newman wrote: > On Sun, Dec 30, 2001 at 09:57:39AM -0600, William Harold Newman wrote: > > On Sun, Dec 30, 2001 at 02:08:43PM +0000, Christophe Rhodes wrote: > > > On Sat, Dec 29, 2001 at 10:53:10AM +0000, Christophe Rhodes wrote: > > > > In other words, merge just with *d-p-d* is my revised advice. > > > > > > And in case no-one disagrees with me (!), here's a patch to do this: > > > > Thank you, I've made that change in 0.pre7.107 (not checked in yet). I > > added an item in NEWS about the change in DIRECTORY's behavior for > > e.g. (DIRECTORY "/tmp/"). > > However, once I tried to run the regression tests on 0.pre7.107, I > found that the patch makes them fail, so I removed it. Fair enough :) > My guess is that the problem is not so much that the patch is wrong, > as that it interacts badly with some implicit assumptions in > %ENUMERATE-DIRECTORIES. %ENUMERATE-DIRECTORIES tries to maintain a > running list (called NODES) of inodes (I think) that it has already > seen, and check for membership in this list to avoid visiting any > inode more than once. With the patch, somehow this goes astray. Thus > when filesys.pure.lisp tests (DIRECTORY "../**/*.*") it doesn't find > any of the files in the current working directory. > > %ENUMERATE-DIRECTORIES is rather convoluted, and I didn't happen to > see an easy fix to make things work, so I just removed the patch for > now, recording the original (DIRECTORY #P"*.*") problem as bug #139. I've poked around a bit at this one, and it's not very pretty. Firstly, note that this problem exists in current sources anyway, though it's less likely to be tickled: * (lisp-implementation-version) "0.6.13" * (length (directory "/home/csr21/misc-cvs/sbcl/tests/../**/*.*")) 425 * (find-if (lambda (pathname) (search "tests" (namestring pathname))) (directory "/home/csr21/misc-cvs/sbcl/tests/../**/*.*")) NIL * (length (directory "/home/csr21/misc-cvs/sbcl/tests/*.*")) 52 Now, the reason that this didn't bite before is that %enumerate-directories only gets this wrong with absolute pathnames, not relative; as it thinks it has already visited tests/, whereas with a relative-pathname passed to %enumerate-directories it doesn't know about tests/ yet. See %enumerate-directories in filesys.lisp; in the absolute case there will be a call looking like (%enumerate-directories "/home/csr21/misc-cvs/sbcl/" ("tests" :up :wild-inferiors) ...) This will pass through the simple-string branch of the typecase, annotating the /home/csr21/misc-cvs/sbcl/tests directory as visited. Aha. The error of logic is in fact the termination condition "(if tail ...)". The thought was that only when the directory is empty (and we've build up the unix path in the first argument to %enumerate-directories) should we get the file listing; otherwise, we're in a directory that we definitely won't be needing. This is wrong, for the above reasoning; (:up [:wild|:wild-inferiors]) will break this assumption. Attached is a revised patch to filesys.lisp which at least passes the regression test... it changes %enumerate-directories to something that I think is correct, but it's cold and I may not have thought it through enough yet... Cheers, Christophe -- Jesus College, Cambridge, CB5 8BL +44 1223 510 299 http://www-jcsu.jesus.cam.ac.uk/~csr21/ (defun pling-dollar (str schar arg) (first (last +))) (make-dispatch-macro-character #\! t) (set-dispatch-macro-character #\! #\$ #'pling-dollar) |
From: William H. N. <wil...@ai...> - 2001-12-31 15:44:24
|
On Mon, Dec 31, 2001 at 12:48:55PM +0000, Christophe Rhodes wrote: > On Sun, Dec 30, 2001 at 01:13:31PM -0600, William Harold Newman wrote: > > On Sun, Dec 30, 2001 at 09:57:39AM -0600, William Harold Newman wrote: > > > On Sun, Dec 30, 2001 at 02:08:43PM +0000, Christophe Rhodes wrote: > > > > On Sat, Dec 29, 2001 at 10:53:10AM +0000, Christophe Rhodes wrote: > > > > > In other words, merge just with *d-p-d* is my revised advice. > > > > > > > > And in case no-one disagrees with me (!), here's a patch to do this: > > > > > > Thank you, I've made that change in 0.pre7.107 (not checked in yet). I > > > added an item in NEWS about the change in DIRECTORY's behavior for > > > e.g. (DIRECTORY "/tmp/"). > > > > However, once I tried to run the regression tests on 0.pre7.107, I > > found that the patch makes them fail, so I removed it. > > Fair enough :) > > > My guess is that the problem is not so much that the patch is wrong, > > as that it interacts badly with some implicit assumptions in > > %ENUMERATE-DIRECTORIES. %ENUMERATE-DIRECTORIES tries to maintain a > > running list (called NODES) of inodes (I think) that it has already > > seen, and check for membership in this list to avoid visiting any > > inode more than once. With the patch, somehow this goes astray. Thus > > when filesys.pure.lisp tests (DIRECTORY "../**/*.*") it doesn't find > > any of the files in the current working directory. > > > > %ENUMERATE-DIRECTORIES is rather convoluted, and I didn't happen to > > see an easy fix to make things work, so I just removed the patch for > > now, recording the original (DIRECTORY #P"*.*") problem as bug #139. > > I've poked around a bit at this one, and it's not very pretty. [...] > Attached is a revised patch to filesys.lisp which at least passes the > regression test... it changes %enumerate-directories to something > that I think is correct, but it's cold and I may not have thought it > through enough yet... Before trying to deal with the new patch, I tried to write a more complete set of tests for DIRECTORY. (I've appended my current draft below my signature.) In the process, I ran into another question that I thought I'd raise on the list. 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/"). Comments? -- 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 ----------------------------------------------------------------------- first part, to be inserted near the end of filesys.test.sh: # Test DIRECTORY on a tree structure of directories. mkdir $testdir cd $testdir touch water dirt mkdir animal plant mkdir animal/vertebrate animal/invertebrate mkdir animal/vertebrate/mammal mkdir animal/vertebrate/snake mkdir animal/vertebrate/bird mkdir animal/vertebrate/mammal/bear mkdir animal/vertebrate/mammal/mythical mkdir animal/vertebrate/mammal/rodent mkdir animal/vertebrate/mammal/ruminant touch animal/vertebrate/mammal/bear/grizzly touch animal/vertebrate/mammal/mythical/mermaid touch animal/vertebrate/mammal/mythical/unicorn touch animal/vertebrate/mammal/rodent/beaver touch animal/vertebrate/mammal/rodent/mouse touch animal/vertebrate/mammal/rodent/rabbit touch animal/vertebrate/mammal/rodent/rat touch animal/vertebrate/mammal/ruminant/cow touch animal/vertebrate/snake/python touch plant/kingsfoil plant/pipeweed $SBCL <<EOF (error "stub: fts.lisp to go here") EOF cd .. rm -r $testdir ----------------------------------------------------------------------- second part, eventually to be inserted into the first part but currently separated into "fts.lisp" for convenience in experimenting with it and editing it in Emacs lisp-mode: ;;;; prototype for filesys.test.sh test of DIRECTORY on tree structure (in-package :cl-user) (defun absolutify (pathname) "Convert a possibly-relative pathname to absolute." (let* ((directory (pathname-directory pathname)) (directory-truename (truename (make-pathname :directory directory))) (absolute-directory (pathname-directory directory-truename))) (merge-pathnames (make-pathname :directory absolute-directory) pathname))) (defun sorted-truenamestrings (pathname-designators) "Convert a collection of pathname designators into canonical form using TRUENAME, NAMESTRING, and SORT." (sort (mapcar #'namestring (mapcar #'truename pathname-designators)) #'string<)) (defun need-match-1 (directory-pathname result-sorted-truenamestrings) "guts of NEED-MATCH" (let ((directory-sorted-truenamestrings (sorted-truenamestrings (directory directory-pathname)))) (unless (equal directory-sorted-truenamestrings result-sorted-truenamestrings) (format t "~&~@<DIRECTORY argument = ~_~2I~S~:>~%" directory-pathname) (format t "~&~@<DIRECTORY result = ~_~2I~S~:>~%" directory-sorted-truenamestrings) (format t "~&~@<expected result = ~_~2I~S.~:>~%" result-sorted-truenamestrings) (error "mismatch between DIRECTORY and expected result")))) (defun need-match (directory-pathname result-pathnames) "Require that (DIRECTORY DIRECTORY-PATHNAME) return RESULT-PATHNAMES (modulo TRUENAME and NAMESTRING applied to each RESULT-PATHNAME for convenience in e.g. converting Unix filename syntax idiosyncrasies to Lisp filename syntax idiosyncrasies)." (let ((sorted-result-truenamestrings (sorted-truenamestrings result-pathnames))) ;; Relative and absolute pathnames should give the same result. (need-match-1 directory-pathname sorted-result-truenamestrings) (need-match-1 (absolutify directory-pathname) sorted-result-truenamestrings))) (defun tests () (need-match "./*.*" '("animal" "dirt" "plant" "water")) (need-match "*.*" '("animal" "dirt" "plant" "water")) (need-match "animal" '("animal")) (need-match "animal/*.*" '("animal/invertebrate" "animal/vertebrate")) (need-match "animal/*/*.*" '("animal/vertebrate/bird" "animal/vertebrate/mammal" "animal/vertebrate/snake")) (need-match "plant/*.*" '("plant/kingsfoil" "plant/pipeweed")) (need-match "plant/**/*.*" '("plant/kingsfoil" "plant/pipeweed")) (need-match "plant/**/**/*.*" '("plant/kingsfoil" "plant/pipeweed")) (let ((vertebrates (mapcar (lambda (stem) (concatenate 'string "animal/vertebrate/" stem)) '("bird" "mammal" "mammal/bear" "mammal/bear/grizzly" "mammal/mythical" "mammal/mythical/mermaid" "mammal/mythical/unicorn" "mammal/rodent" "mammal/rodent/beaver" "mammal/rodent/mouse" "mammal/rodent/rabbit" "mammal/rodent/rat" "mammal/ruminant" "mammal/ruminant/cow")))) (need-match "animal/vertebrates/**/*.*" vertebrates) (need-match "animal/vertebrates/mammal/../**/*.*" vertebrates) (need-match "animal/vertebrates/mammal/../**/**/*.*" vertebrates) (need-match "animal/vertebrates/mammal/mythical/../**/../**/*.*" vertebrates)) (need-match "animal/vertebrates/**/robot.*" nil) (need-match "animal/vertebrates/mammal/../**/*.robot" nil) (need-match "animal/vertebrates/mammal/../**/robot/*.*" nil) (need-match "animal/vertebrates/mammal/robot/../**/../**/*.*" nil)) |
From: Christophe R. <cs...@ca...> - 2001-12-31 18:28:21
|
On Mon, Dec 31, 2001 at 09:33:59AM -0600, William Harold Newman wrote: > On Mon, Dec 31, 2001 at 12:48:55PM +0000, Christophe Rhodes wrote: > > I've poked around a bit at this one, and it's not very pretty. > [...] > > Attached is a revised patch to filesys.lisp which at least passes the > > regression test... it changes %enumerate-directories to something > > that I think is correct, but it's cold and I may not have thought it > > through enough yet... > > Before trying to deal with the new patch, I tried to write a more > complete set of tests for DIRECTORY. (I've appended my current draft > below my signature.) In the process, I ran into another question that > I thought I'd raise on the list. > > 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/"). > > Comments? I agree with you here, certainly. There may be issues of "usefulness" in that it may become harder to investigate directory trees, but I believe that your instinct (to have everything consistent at the lisp level) is the right one. > (in-package :cl-user) > > (defun absolutify (pathname) > "Convert a possibly-relative pathname to absolute." > (let* ((directory (pathname-directory pathname)) > (directory-truename (truename (make-pathname :directory directory))) Careful -- you can't take the truename of a wild pathname... > (absolute-directory (pathname-directory directory-truename))) > (merge-pathnames (make-pathname :directory absolute-directory) > pathname))) > '("bird" > "mammal" > "mammal/bear" "mammal/bear/grizzly" > "mammal/mythical" "mammal/mythical/mermaid" > "mammal/mythical/unicorn" > "mammal/rodent" "mammal/rodent/beaver" > "mammal/rodent/mouse" "mammal/rodent/rabbit" > "mammal/rodent/rat" > "mammal/ruminant" "mammal/ruminant/cow")))) Do you not need a snake in here? > (need-match "animal/vertebrates/**/*.*" vertebrates) ^^^^^^^^^^^ This line (and the few following) want to have "vertebrate" in the directory name. As you might tell, I've tried running these with the patch I posted earlier today, and (barring these things I've drawn attention to) it produces reasonable output. I've also noticed that the tests depend on TMPDIR being set in side-effectful-pathnames -- there probably wants to be a ${TMPDIR:-/tmp} in there... Cheers, Christophe -- Jesus College, Cambridge, CB5 8BL +44 1223 510 299 http://www-jcsu.jesus.cam.ac.uk/~csr21/ (defun pling-dollar (str schar arg) (first (last +))) (make-dispatch-macro-character #\! t) (set-dispatch-macro-character #\! #\$ #'pling-dollar) |
From: William H. N. <wil...@ai...> - 2002-01-10 00:23:54
|
On Mon, Dec 31, 2001 at 06:28:00PM +0000, Christophe Rhodes wrote: [...] > Do you not need a snake in here? [...and various other useful suggestions...] > > (need-match "animal/vertebrates/**/*.*" vertebrates) > As you might tell, I've tried running these with the patch I posted > earlier today, and (barring these things I've drawn attention to) it > produces reasonable output. I've also noticed that the tests depend on > TMPDIR being set in side-effectful-pathnames -- there probably wants > to be a ${TMPDIR:-/tmp} in there... OK, I've finally merged the patch (in sbcl-0.pre7.119). I think I made all the changes you suggested too. Thank you. -- William Harold Newman <wil...@ai...> "Our users will know fear and cower before our software! Ship it! Ship it and let them flee like the dogs they are!" -- Klingon programmer PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C |
From: Daniel B. <da...@te...> - 2002-01-01 02:15:18
|
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. 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. Happy New Year -dan -- http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources |
From: William H. N. <wil...@ai...> - 2002-01-01 14:58:45
|
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 |