Re: proposal: probe-file -- major behavior change

>>>>> "Sam" == Sam Steingold <sds@...> 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

Thread view

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&gt;
Read, think and remember! <http://www.iris.org.il&gt; <http://www.memri.org/&gt;
Lottery is a tax on statistics ignorants. MS is a tax on computer-idiots.

>>>>> "Sam" == Sam Steingold <sds@...> 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

>>>>> "Sam" == Sam Steingold <sds@...> writes:
>> * In message <4n664ki2kz.fsf@...>
>> * On the subject of "Re: proposal: probe-file -- major behavior change"
>> * Sent on 26 Feb 2002 12:18:36 -0500
>> * Honorable Raymond Toy <toy@...> writes:
>>
>> >>>>> "Sam" == Sam Steingold <sds@...> 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

> * In message <4nit8jhni7.fsf@...>
> * On the subject of "Re: proposal: probe-file -- major behavior change"
> * Sent on 26 Feb 2002 17:44:16 -0500
> * Honorable Raymond Toy <toy@...> writes:
>
> >>>>> "Sam" == Sam Steingold <sds@...> 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&gt;
Read, think and remember! <http://www.iris.org.il&gt; <http://www.memri.org/&gt;
Even Windows doesn't suck, when you use Common Lisp

>>>>> "Sam" == Sam Steingold <sds@...> writes:
>> * In message <4nit8jhni7.fsf@...>
>> * On the subject of "Re: proposal: probe-file -- major behavior change"
>> * Sent on 26 Feb 2002 17:44:16 -0500
>> * Honorable Raymond Toy <toy@...> writes:
>>
>> >>>>> "Sam" == Sam Steingold <sds@...> 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

Sam Steingold <sds@...> 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