From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#36490: 26.1; directory-files-recursively breaks when it encounters a directory named "~" Date: Tue, 09 Jul 2019 20:23:02 +0300 Message-ID: <83sgrf3yx5.fsf@gnu.org> References: <87muhvyotd.fsf@gmx.de> <87zhlo1bfl.fsf@mouse.gnus.org> <83bly35igd.fsf@gnu.org> <8336jf5grv.fsf@gnu.org> <83wogr40pc.fsf@gnu.org> <83v9wb40bf.fsf@gnu.org> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="14286"; mail-complaints-to="usenet@blaine.gmane.org" Cc: 36490@debbugs.gnu.org, erik_hahn@gmx.de To: Lars Ingebrigtsen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Jul 09 19:30:45 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hktwy-0003Za-Ec for geb-bug-gnu-emacs@m.gmane.org; Tue, 09 Jul 2019 19:30:44 +0200 Original-Received: from localhost ([::1]:52358 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hktwx-0003Zn-CO for geb-bug-gnu-emacs@m.gmane.org; Tue, 09 Jul 2019 13:30:43 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57742) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hktqY-0006dV-WA for bug-gnu-emacs@gnu.org; Tue, 09 Jul 2019 13:24:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hktqX-00049I-37 for bug-gnu-emacs@gnu.org; Tue, 09 Jul 2019 13:24:06 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:53515) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hktqU-00046A-0A for bug-gnu-emacs@gnu.org; Tue, 09 Jul 2019 13:24:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hktqT-0007fv-OC for bug-gnu-emacs@gnu.org; Tue, 09 Jul 2019 13:24:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 09 Jul 2019 17:24:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 36490 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: confirmed Original-Received: via spool by 36490-submit@debbugs.gnu.org id=B36490.156269301029465 (code B ref 36490); Tue, 09 Jul 2019 17:24:01 +0000 Original-Received: (at 36490) by debbugs.gnu.org; 9 Jul 2019 17:23:30 +0000 Original-Received: from localhost ([127.0.0.1]:34103 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hktpx-0007fB-Gu for submit@debbugs.gnu.org; Tue, 09 Jul 2019 13:23:29 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:44958) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hktpt-0007ex-O8 for 36490@debbugs.gnu.org; Tue, 09 Jul 2019 13:23:26 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:55162) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hktpo-0003Cf-BM; Tue, 09 Jul 2019 13:23:20 -0400 Original-Received: from [176.228.60.248] (port=4537 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hktpm-0003GX-1a; Tue, 09 Jul 2019 13:23:19 -0400 In-reply-to: (message from Lars Ingebrigtsen on Tue, 09 Jul 2019 19:00:13 +0200) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:162530 Archived-At: > From: Lars Ingebrigtsen > Cc: 36490@debbugs.gnu.org, erik_hahn@gmx.de > Date: Tue, 09 Jul 2019 19:00:13 +0200 > > Eli Zaretskii writes: > > > Sorry, that's not what I meant to say. I meant to say how would a > > Lisp program know whether (expand-file-name "~/") means the home > > directory or a directory whose name is literally "~"? > > Well, we have documented that in expand-file-name "~/" means the home > directory, and I have no problems with that. Documenting a problem doesn't necessarily solve it. E.g., it is also documented that you must quote file names with special characters, but you still raised the objection that the "~" use case makes that "odd". I'm saying that the "~/" use case is "odd" as well, and for the same reasons. > "~/" 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. I say we should fix this problem in a way that isn't fragile, and doesn't crucially depend on what the current code does or avoids doing. > > Btw, stuff like (expand-file-name "foo/~/") already does what you > > want, so the problem is only with the leading '~', and can be avoided > > if we avoid that situation. IOW, why should this example: > > > > (expand-file-name "~" "/tmp/") > > => "/home/larsi" > > > > determine how directory-files-recursively behaves? > > 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.