bug#12517: 24.2; (file-name-directory "~") returns nil

bug#12517: 24.2; (file-name-directory "~") returns nil

[Leo]

I was bitten by this corner case that (file-name-directory "~") returns
nil. I wonder if this is a bug/oversight?

Leo

bug#12517: 24.2; (file-name-directory "~") returns nil

[Andreas Schwab]

Leo <sdl.web@gmail.com> writes:

> I was bitten by this corner case that (file-name-directory "~") returns
> nil. I wonder if this is a bug/oversight?

That's not different from (file-name-directory "a").  The function works
purely textual and does not expand the argument, you have to call
expand-file-name yourself.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

bug#12517: 24.2; (file-name-directory "~") returns nil

[Eli Zaretskii]

> From: Leo <sdl.web@gmail.com>
> Date: Wed, 26 Sep 2012 10:35:10 +0800
> 
> I was bitten by this corner case that (file-name-directory "~") returns
> nil.

As does (file-name-directory "a").

> I wonder if this is a bug/oversight?

I think it is neither.  file-name-directory works on the syntax of its
argument, not on its semantics.  The ELisp manual says:

 -- Function: file-name-directory filename
     This function returns the directory part of FILENAME, as a
     directory name (*note Directory Names::), or `nil' if FILENAME
     does not include a directory part.

"FILENAME does not include a directory part" means literally that: the
string FILENAME must _include_ a directory part for
file-name-directory to return a non-nil result.

If you want the directory of its argument, even if the argument is
given as any kind of shorthand, run that argument through
expand-file-name first.

bug#12517: 24.2; (file-name-directory "~") returns nil

[Stefan Monnier]

>> I was bitten by this corner case that (file-name-directory "~") returns
>> nil. I wonder if this is a bug/oversight?

I don't know if it should be treated as a misfeature, but at least I've
already relies on it in code such as locate-dominating-file, which
I quote:

  ;; Represent /home/luser/foo as ~/foo so that we don't try to look for
  ;; `name' in /home or in /.
  (setq file (abbreviate-file-name file))


-- Stefan

bug#12517: 24.2; (file-name-directory "~") returns nil

[Leo]

Thanks to all for the explanations. Closing.