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

Previous Next

Full log

View this message in rfc822 format

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 36490 <at> debbugs.gnu.org, Lars Ingebrigtsen <larsi <at> gnus.org>, erik_hahn <at> gmx.de
Subject: bug#36490: 26.1; directory-files-recursively breaks when it encounters a directory named "~"
Date: Tue, 09 Jul 2019 20:16:56 +0200

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

>> expand-file-name's use case is to (basically) concatenate a directory
>> name and a file name, but it's used instead of concat because nobody
>> wants to care about whether the directory name has a trailing slash or
>> not.
>
> Ah, but when the file name begins with a "~", the "concatenation" does
> more than what meets the eye.
>
>> That's basically the use case for expand-file-name, and using it has
>> avoided a lot of basic concatenation problems over the years (because
>> Emacs allows sloppy handling of directory file names in most
>> situations).
>
> I think this is a simplification.  It ignores the fact that
> expand-file-name interprets ~/, it ignores the fact that it does
> arbitrary stuff for "remote" file names, it ignores the fact that on
> Windows it prepends the drive letter if there isn't one already, etc.
> IOW, expand-file-name is concatenation-like, but it has a few tricks
> up its sleeve, and in this case the trick works against us.  We need
> to disable that trick to support files and directories whose names
> begin with a literal "~".  I see no way around that.

For the records, I second Eli. See also the discussion in bug#16984. And
yes, I believe it makes sense to quote file names (suppress special
meaning of "~") in the loop of directory-files-recursively.

Best regards, Michael.

Previous Next

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