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

[David Kastrup]

eliz@is.elta.co.il (Eli Zaretskii) writes:

> On 27 Feb 2002, David Kastrup wrote:
> 
> > a) just leave it alone.  Someone else will have to deal with it.
> 
> We need to establish whether the callers of expand-file-name indeed can 
> deal with that.  Since an empty string is what you get by typing RET to a 
> prompt, it's quite possible that some application code counts on this 
> behavior.
> 
> I also think callers trust expand-file-name to return a valid absolute 
> file name, which "" isn't.

I don't think callers can trust expand-file-name to return a valid
absolute file name if it is given an illegal file name to start with.

I tried the simple-minded

(defadvice expand-file-name (around exp-nonempty activate)
  (if (zerop (length (ad-get-arg 0)))
      (setq ad-return-value (ad-get-arg 0))
    ad-do-it))

for checking this out, but that seems to have bad effects: calling
(expand-file-name ".")  then delivers "/".  Hmmm.

> I don't mean to say that expand-file-name should be left alone, but
> before we change anything, some footwork is required.  We might
> break more than we fix.

Well, that would not have been the first case...  sorting things out
is sometimes a necessary part of the development cycle.

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