GNU bug report logs - #36490
26.1; directory-files-recursively breaks when it encounters a directory named "~"

Previous Next

Full log

Message #64 received at 36490 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 36490 <at> debbugs.gnu.org, erik_hahn <at> gmx.de
Subject: Re: bug#36490: 26.1;
 directory-files-recursively breaks when it encounters a directory
 named "~"
Date: Wed, 10 Jul 2019 13:55:33 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> "~/" isn't something you'll ever get from functions like
>> directory-files
>
> That's sheer luck, because:
>
>   (file-name-as-directory "~")
>     => "~/"
>
> So just running "~" through an innocent API gives you a "magic"
> directory name (if you consider "~" not "magic" by itself).  How is
> this different from the "odd" use case where one must quote "~" to
> avoid its interpretation as the home directory?  Who can guarantee
> that some day directory-files-recursively will not want to do
> something like the above?  If it does, we will be right back at the
> same problem.

Well...  That kinda sounds odd to me.

"~/" is not, and never will be, a valid file name in any OS that Emacs
is going to support from now on.  So having that have a special meaning
in `expand-file-name' is not surprising.  Having "~" do something
special is surprising.

But changing that is probably not going to happen, so how about just
clarifying the documentation in that function to say what "~" means
explicitly instead of the caller having to guess?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.