Re: file-readable-p returns t for empty string

[David Kastrup]

abraham@dina.kvl.dk (Per Abrahamsen) writes:

> David.Kastrup@t-online.de (David Kastrup) writes:
> 
> > Well, expanding "" (which would yield an error if you tried it opening
> > under any operating system) to ".", an entirely different file, is
> > equally absurd.  
> 
> It may be absurd, but it is common behavior in many applications.  I
> think on the principle of least surprise, "" should either expand to
> the current directory, or generate an error.

> Or the man page to cd(1):

That's a user application.

> Or Java
>     
>     Parent directory path components ("..") and current directory path
>     components (".") are eliminated wherever possible, and trailing
>     slashes and redundant slashes are always removed (except where the
>     path is simply "/"). Also, the parent of the root directory is assumed
>     to be itself. If the empty string is supplied, the returned path is
>     "."

The problem is not so much that expand-file-name as a user-called
routine returns "." for "", the problem is that expand-file-name is
called implicitly in a lot of cases in Emacs.  While one could argue
for and against this particular behaviour for expand-file-name
itself, the point is that it also reflects on routines like
(file-readable-p), (file-directory-p) and the like.  Java presumably
gives one an open call for files that will not magically turn "" into
"." unless you explicitly call the named function.

But in Emacs Lisp, everything gets routed through expand-file-name,
and in that case this silent change is surprising.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Email: David.Kastrup@t-online.de