From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Allen Li Newsgroups: gmane.emacs.bugs Subject: bug#29465: 25.3; Confusing message for dired-do-shell-command substitution Date: Tue, 28 Nov 2017 00:25:17 -0800 Message-ID: References: <83vahv67eb.fsf@gnu.org> <87fu8zukmb.fsf@gmail.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1511857572 18175 195.159.176.226 (28 Nov 2017 08:26:12 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 28 Nov 2017 08:26:12 +0000 (UTC) Cc: 29465@debbugs.gnu.org, rms@gnu.org To: Tino Calancha Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Nov 28 09:26:07 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eJbDS-0004In-7S for geb-bug-gnu-emacs@m.gmane.org; Tue, 28 Nov 2017 09:26:06 +0100 Original-Received: from localhost ([::1]:36521 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eJbDZ-0005yT-82 for geb-bug-gnu-emacs@m.gmane.org; Tue, 28 Nov 2017 03:26:13 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39306) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eJbDS-0005xB-6c for bug-gnu-emacs@gnu.org; Tue, 28 Nov 2017 03:26:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eJbDP-0003wf-0I for bug-gnu-emacs@gnu.org; Tue, 28 Nov 2017 03:26:06 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:52984) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eJbDO-0003w9-TE for bug-gnu-emacs@gnu.org; Tue, 28 Nov 2017 03:26:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1eJbDO-00045M-8G for bug-gnu-emacs@gnu.org; Tue, 28 Nov 2017 03:26:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Allen Li Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 28 Nov 2017 08:26:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 29465 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 29465-submit@debbugs.gnu.org id=B29465.151185752615659 (code B ref 29465); Tue, 28 Nov 2017 08:26:02 +0000 Original-Received: (at 29465) by debbugs.gnu.org; 28 Nov 2017 08:25:26 +0000 Original-Received: from localhost ([127.0.0.1]:33432 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eJbCo-00044V-3u for submit@debbugs.gnu.org; Tue, 28 Nov 2017 03:25:26 -0500 Original-Received: from mail-qt0-f179.google.com ([209.85.216.179]:36701) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eJbCl-00044F-Vs for 29465@debbugs.gnu.org; Tue, 28 Nov 2017 03:25:24 -0500 Original-Received: by mail-qt0-f179.google.com with SMTP id a19so42631837qtb.3 for <29465@debbugs.gnu.org>; Tue, 28 Nov 2017 00:25:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=W+80SPk3GKBau3QrxA50DQKexqIfqNFQ25ONmwKzZxU=; b=TFWntESuHFSiW/NS+2yBMST3JMme9fQH94aOEhoN9gEL3pAaVqNgUgWxrqCp9GWLJs Y6w3HfCnGNEPPIB0kVQhjKDWMemUyNqhi7asGIrfj09zIYAhFbUPIY4VPwX+ha7YMScn ziEMaT4wPGHDG7+meN9Caj3a42ncHOpwL6aO1vxT0idoVt8QgX3dBD/+oYpMwwwfViPe Lb8elkCxJQODhgymbxo03i8tgCSEweG+lOkIUUshmL1P5l475gmoekKEeQKuRmqTqyM/ cU3unZrHDxCDMz2Is4Kmfct9iWSoDQ297LLQbQqSYKZ8zc4XkiKCeW/AZInuUDLGlT7m AdTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=W+80SPk3GKBau3QrxA50DQKexqIfqNFQ25ONmwKzZxU=; b=ecFilge4UJfm6kZDKX5vq+1go9RuhXFCy0DwXA6tW1yugx3oI3WXsL9JT97ajC+q1u Uj4dEFi9Nt1CmRlQTKrmJMnS9ANYy50kRp2gnbY2+6C9KJeKV3GmF+RWCqVNdzqQ02FC PZ7iuRdvC/RvN81rQpmqSi8oF6wQWak/FUKwU/d5GaBLaGIDVLuDyXDcZdwioH43iKgC fgqagNMJD7o9djCleoROSWT1HVaLD4hqVjDieRsVGGjWY7LC5nLSy9bE65I5Dc639vrP uNOg4dztWY9p3/iqOL//fz3AarPTIeentmpOyX+5L8kTGTcGiaOpW5rgrcX4hXgTQlZm 4zng== X-Gm-Message-State: AJaThX70kfI/KjEmk8VwcSi2Tz4am9rmDBZKujI70D8RPcGCKlytN4Gs fcw/uf0SRrYWe8Fcpld7x5YtG7tMce3xK5e4AIk= X-Google-Smtp-Source: AGs4zMbb+1NLZA3W5APFVa2aUSii1dlWI+ESgCAQHDuWs1Xu5fTanuG+fA7vQK5JHx+rGymfCL0F+9X2QAwjEaUPA9g= X-Received: by 10.200.45.168 with SMTP id p37mr64206330qta.247.1511857518142; Tue, 28 Nov 2017 00:25:18 -0800 (PST) Original-Received: by 10.237.52.161 with HTTP; Tue, 28 Nov 2017 00:25:17 -0800 (PST) In-Reply-To: <87fu8zukmb.fsf@gmail.com> 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: 208.118.235.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:140482 Archived-At: On Mon, Nov 27, 2017 at 7:50 PM, Tino Calancha wr= ote: > FWIW the confirmation was added by RMS in 2002 > (eab9ed67eb50bab4fc736058a799508d544606a0). > See also commits: > commit e52c37fad057b29d68c51cf3a70b2e0d94f656cb > commit edb8d73e62552cf2f95cbf871050913862dc5f18 > > My commit "Ask confirmation for all suspicious wildcards" > (6e39940adba7b96dfe520caa52a1b92a1a84a84f) > extends that confirmation to cover Bug#27496. > > Before 6e39940adb, not all `?' or `*' were checked for > being between white spaces: > ! echo ./? RET ; This ask confirmation > ! echo ./? ? RET ; This doesn't > > After 6e39940adb, all occurrences of `?' or `*' are checked for > being between white spaces; the user is asked confirmation if > any of them are not surrounded by whites. > I made this change for consistency: I thought it has sense to > check all `?' `*' occurrences, not just one. > > In fact, this change causes that you are prompted in your snippet: > ! find * -name '*.txt' RET > ;; After (before) 6e39940adb you are (not) prompted. > > Compare with the following: > ! find ? -name '*.txt' RET > ;; After and before 6e39940adb you are prompted. > > Your second patch disables the confirmation prompts that have > being around since 2002. Since the source of this bug report > seems to be 6e39940adb, I would rather revert just this commit. I see. I actually do not have your commit yet (on 25.3.1), so I am encountering the inconsistent behavior that you fixed. However, your commit doesn't solve the problem that the message is misleading; unfortunately by making the prompt appear consistently the message is now even more confusing. Before (right now on 25.3.1), this did not show a prompt: find * -name '*.txt' Now it does show a prompt: Confirm--do you mean to use `*' as a wildcard? I would have no idea what this means. Does it mean that Dired is going to replace the *? Does it mean that Dired is going to replace the =E2=80=99*.txt=E2=80=99? Or perhaps both? What am I confirming exactl= y? The second issue is that the prompt is very annoying for advanced users; I have filed a second bug for this (#29190). Since your commit fixes the inconsistency problem, that's one less reason for my advocating to remove the confirmation. If we can make the message less confusing and add an option to disable the prompt, I would be happy. However, I think writing a useful confirmation prompt for this is hard; hopefully someone has a good idea. One idea would be what Eli suggested: Are you sure you want `*' to be passed to the shell? However, what if the command contains both `*' and `?'? find * -name =E2=80=99*.txt=E2=80=99 -o -name =E2=80=99x??=E2=80=99 Are you sure you want `*' to be passed to the shell? (Does that include the `?' or not?) What if the user typos the intended substitution character? find *x -name =E2=80=99*.txt=E2=80=99 -o -name =E2=80=99x??=E2=80=99 Are you sure you want `*' to be passed to the shell? (Which one?) Since I was not confident that a good message could be written, I suggested removing the confirmation. Also, I am not sure what this is supposed to be protecting against. It seems more useful to confirm when dired-do-shell-command is going to replace * or ? rather than when it is not. If the user did not read the documentation string, the user would most likely expect these characters to be passed to the shell. If the user did read the documentation string, the prompt would only be an annoyance. The original commit by RMS (eab9ed67eb50bab4fc736058a799508d544606a0) does not provide a reason for the confirmation. If I were to hazard a guess, the behavior of the command was changed, so the prompt was added to warn users accustomed to the old behavior. However, it is now 15 years since; I don=E2=80=99t think there=E2=80=99s any value keeping= the confirmation around for its original (?) purpose.