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

[David Kastrup]

rms@gnu.org (Richard Stallman) writes:

>     That's because all these primitives call expand-file-name internally,
>     and expand-file-name returns the buffer's default directory when
>     passed an empty string as an argument.
> 
>     I don't know off the top of my head why does expand-file-name do that.
> 
> Do you have something better to suggest?

The empty string is illegal as a file name under most operating
systems, I would guess.  So what is expand-file-name to do with a
syntactically illegal name?  I see three possibilities:

a) just leave it alone.  Someone else will have to deal with it.
b) return NIL
c) signal an error

When we currently have something like (expand-file-name
"~nonexistant/file"), we get an expanded path
"/home/dak/~nonexistant/file", and things like file-exists-p get their
chance to find it does not exist.  Namely, illegal looking path
components are kept as-is.  Unfortunately, with "" this is not a good
option for a mere path *component* since it changes an illegal file
name to a legal directory name if we tack on the default directory.

b) would probably be the most logical option (meaning "can't deal with
expanding this"), but might make things fail that do not expext
expand-file-name to return anything but a string when fed a string.

So I'd think a) the most expedient.

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