From: Sam S. <sd...@gn...> - 2002-02-24 18:24:13
|
now: (probe-file "/foo/bar") ==> nil (probe-file "/etc") ==> *** - PROBE-FILE: "/etc" names a directory, not a file (probe-file "/etc/") ==> *** - no file name given: #P"/etc/" I think this is inconsistent and non-compliant ("An error of type file-error is signaled if the file system cannot perform the requested operation.") there are no file system problems with "/etc" or "/etc/". most important is that the users (see <clisp-list>) appear to expect PROBE-FILE to work on directories too. thus I propose to ditch PROBE-DIRECTORY and make (probe-file "/etc/") ==> #p"/etc/" (probe-file "/etc") ==> #p"/etc/" (same!) or NIL rationale: all file systems which CLISP supports (I don't know about Acorn and Amiga, but I expect them to be same) cannot have a file and a subdirectory with the same name in one directory, so mapping "/etc" to #p"/etc/" is unambiguous (and the user probably means the same). OTOH, CMUCL (probe-file "/etc") ==> #p"/etc" is obviously wrong (there is no such file in #p"/"). So, (probe-directory foo) == (let ((p (probe-file foo))) (and p (null (pathname-name p)) (null (pathname-type p)))) another thing: (pathname ".bashrc") ==> #(pathname :type "bashrc") is _not_ what anyone may ever expect these days. at the very least, there should be a user option custom:*parse-namestring-starts-with-dot* (a better name?) with possible values :NAME or :TYPE what do people here think? -- Sam Steingold (http://www.podval.org/~sds) running RedHat7.2 GNU/Linux Keep Jerusalem united! <http://www.onejerusalem.org/Petition.asp> Read, think and remember! <http://www.iris.org.il> <http://www.memri.org/> Lottery is a tax on statistics ignorants. MS is a tax on computer-idiots. |
From: Raymond T. <to...@rt...> - 2002-02-26 17:18:55
|
>>>>> "Sam" == Sam Steingold <sd...@gn...> writes: Sam> now: Sam> (probe-file "/foo/bar") ==> nil Sam> (probe-file "/etc") ==> *** - PROBE-FILE: "/etc" names a directory, not a file Sam> (probe-file "/etc/") ==> *** - no file name given: #P"/etc/" Sam> I think this is inconsistent and non-compliant ("An error of type Sam> file-error is signaled if the file system cannot perform the requested Sam> operation.") there are no file system problems with "/etc" or "/etc/". Sam> most important is that the users (see <clisp-list>) appear to expect Sam> PROBE-FILE to work on directories too. Sam> thus I propose to ditch PROBE-DIRECTORY and make Sam> (probe-file "/etc/") ==> #p"/etc/" Sam> (probe-file "/etc") ==> #p"/etc/" (same!) or NIL Sam> rationale: Sam> all file systems which CLISP supports (I don't know about Acorn and Sam> Amiga, but I expect them to be same) cannot have a file and a Sam> subdirectory with the same name in one directory, so mapping "/etc" to Sam> #p"/etc/" is unambiguous (and the user probably means the same). Sam> OTOH, CMUCL (probe-file "/etc") ==> #p"/etc" is obviously wrong (there Sam> is no such file in #p"/"). I don't think that this is so wrong. Some OSs (Solaris) still actually let you read a directory as a file. Well, at least "cat /etc" produces something. So maybe someone really wants to know that /etc exists? Sam> another thing: Sam> (pathname ".bashrc") ==> #(pathname :type "bashrc") Sam> is _not_ what anyone may ever expect these days. Sam> at the very least, there should be a user option Sam> custom:*parse-namestring-starts-with-dot* Sam> (a better name?) with possible values :NAME or :TYPE Sam> what do people here think? Don't know about the user option variable, but I agree. The name portion of ".bashrc" should be ".bashrc", not type "bashrc". And the name of "foo.bar.baz.lisp" should have a name of "foo.bar.baz" with type "lisp"? Ray |
From: Sam S. <sd...@gn...> - 2002-02-26 19:33:31
|
> * In message <4n6...@rt...> > * On the subject of "Re: proposal: probe-file -- major behavior change" > * Sent on 26 Feb 2002 12:18:36 -0500 > * Honorable Raymond Toy <to...@rt...> writes: > > >>>>> "Sam" == Sam Steingold <sd...@gn...> writes: > > Sam> OTOH, CMUCL (probe-file "/etc") ==> #p"/etc" is obviously wrong (there > Sam> is no such file in #p"/"). > > I don't think that this is so wrong. Some OSs (Solaris) still > actually let you read a directory as a file. Well, at least "cat > /etc" produces something. In CL, there is a big difference between a file and a directory. > So maybe someone really wants to know that /etc exists? so how is the user supposed to find out whether /etc is a file or directory? both CLISP and CMUCL have non-portable ways to do that. I propose to make PROBE-FILE useable for that. -- Sam Steingold (http://www.podval.org/~sds) running RedHat7.2 GNU/Linux Keep Jerusalem united! <http://www.onejerusalem.org/Petition.asp> Read, think and remember! <http://www.iris.org.il> <http://www.memri.org/> Those who can't write, write manuals. |
From: Raymond T. <to...@rt...> - 2002-02-26 22:44:23
|
>>>>> "Sam" == Sam Steingold <sd...@gn...> writes: >> * In message <4n6...@rt...> >> * On the subject of "Re: proposal: probe-file -- major behavior change" >> * Sent on 26 Feb 2002 12:18:36 -0500 >> * Honorable Raymond Toy <to...@rt...> writes: >> >> >>>>> "Sam" == Sam Steingold <sd...@gn...> writes: >> Sam> OTOH, CMUCL (probe-file "/etc") ==> #p"/etc" is obviously wrong (there Sam> is no such file in #p"/"). >> >> I don't think that this is so wrong. Some OSs (Solaris) still >> actually let you read a directory as a file. Well, at least "cat >> /etc" produces something. Sam> In CL, there is a big difference between a file and a directory. But a file is a named entry in a file system, having an implementation-defined nature. so I'm not sure what the right answer is. I can't find the glossary entry for directory. >> So maybe someone really wants to know that /etc exists? Sam> so how is the user supposed to find out whether /etc is a file or Sam> directory? Sam> both CLISP and CMUCL have non-portable ways to do that. Sam> I propose to make PROBE-FILE useable for that. I don't know. If CL doesn't specify a way to tell if /etc is a file or directory, whatever you do is non-portable, so you might as well make it non-portable. Ray |
From: Sam S. <sd...@gn...> - 2002-02-27 01:52:52
|
> * In message <4ni...@rt...> > * On the subject of "Re: proposal: probe-file -- major behavior change" > * Sent on 26 Feb 2002 17:44:16 -0500 > * Honorable Raymond Toy <to...@rt...> writes: > > >>>>> "Sam" == Sam Steingold <sd...@gn...> writes: > > Sam> In CL, there is a big difference between a file and a directory. > > But a file is > > a named entry in a file system, having an > implementation-defined nature. > > so I'm not sure what the right answer is. I can't find the glossary > entry for directory. on unix, there is really no difference between "/etc" and "/etc/". in CL, there is difference between #p"/etc" and #p"/etc/" wrt the values accessors and other functions return. > >> So maybe someone really wants to know that /etc exists? > > Sam> so how is the user supposed to find out whether /etc is a file or > Sam> directory? > Sam> both CLISP and CMUCL have non-portable ways to do that. > Sam> I propose to make PROBE-FILE useable for that. > > I don't know. If CL doesn't specify a way to tell if /etc is a file > or directory, whatever you do is non-portable, so you might as well > make it non-portable. I prefer the occam's razor - do not multiply entities unnecessarily. if PROBE-FILE can be made to differenciate between the two, why invent a separate function? -- Sam Steingold (http://www.podval.org/~sds) running RedHat7.2 GNU/Linux Keep Jerusalem united! <http://www.onejerusalem.org/Petition.asp> Read, think and remember! <http://www.iris.org.il> <http://www.memri.org/> Even Windows doesn't suck, when you use Common Lisp |
From: Raymond T. <to...@rt...> - 2002-02-27 14:22:56
|
>>>>> "Sam" == Sam Steingold <sd...@gn...> writes: >> * In message <4ni...@rt...> >> * On the subject of "Re: proposal: probe-file -- major behavior change" >> * Sent on 26 Feb 2002 17:44:16 -0500 >> * Honorable Raymond Toy <to...@rt...> writes: >> >> >>>>> "Sam" == Sam Steingold <sd...@gn...> writes: >> Sam> In CL, there is a big difference between a file and a directory. >> >> But a file is >> >> a named entry in a file system, having an >> implementation-defined nature. >> >> so I'm not sure what the right answer is. I can't find the glossary >> entry for directory. Sam> on unix, there is really no difference between "/etc" and "/etc/". I think on Mac OS X "ls /etc" and "ls /etc/" return 2 different answers. I can't check right now, though. I don't know if that's because of ls or because of the system. Sam> in CL, there is difference between #p"/etc" and #p"/etc/" wrt the Sam> values accessors and other functions return. Yes. >> >> So maybe someone really wants to know that /etc exists? >> Sam> so how is the user supposed to find out whether /etc is a file or Sam> directory? Sam> both CLISP and CMUCL have non-portable ways to do that. Sam> I propose to make PROBE-FILE useable for that. >> >> I don't know. If CL doesn't specify a way to tell if /etc is a file >> or directory, whatever you do is non-portable, so you might as well >> make it non-portable. Sam> I prefer the occam's razor - do not multiply entities unnecessarily. Sam> if PROBE-FILE can be made to differenciate between the two, why invent Sam> a separate function? Well, I think Occam's razor goes both ways here. PROBE-FILE should do just one thing. :-) If you think this is the right thing to do, it's ok. It's non-portable, but for pragmatic reasons I'd make probe-file work the same way as other CL systems do, assuming there's some consistency. On a side note, this gets an error: (with-open-file (s #p"/etc" :direction :input :element-type '(unsigned-byte 8)) (let ((d (make-array 256 :element-type '(unsigned-byte 8)))) (read-sequence d s))) whether I use /etc or /etc/ (but different errors). Am I not allowed to open a directory even on a system (Solaris) that lets me do that? CMUCL reads it in ok. Ray |
From: Todd S. <ts...@op...> - 2002-02-27 03:49:59
|
Sam Steingold <sd...@gn...> writes: > rationale: > all file systems which CLISP supports (I don't know about Acorn and > Amiga, but I expect them to be same) cannot have a file and a > subdirectory with the same name in one directory, so mapping "/etc" to > #p"/etc/" is unambiguous (and the user probably means the same). I don't know the first thing about the CL functions in question, but on win32 it's possible to have a Registry key and value with the same name under the same parent key. If you wanted to expose the Registry through the normal filesystem interface (which at first blush strikes me as more natural than the dirkey stuff), then you'd need the ability to have a file and dir with the same name. The registry also allows values (files) with the empty string for their name. Is that expressible with CL pathnames? Todd |