all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Allen Li <vianchielfaura@gmail.com>
Cc: 29465@debbugs.gnu.org, tino.calancha@gmail.com
Subject: bug#29465: 25.3; Confusing message for dired-do-shell-command substitution
Date: Tue, 28 Nov 2017 18:26:52 +0200	[thread overview]
Message-ID: <83609u5pyr.fsf@gnu.org> (raw)
In-Reply-To: <CAJr1M6cuB0RPcUfzsGHCGt+8m6-KH58FX4NoD==APb7dksrs2g@mail.gmail.com> (message from Allen Li on Tue, 28 Nov 2017 00:25:17 -0800)

> From: Allen Li <vianchielfaura@gmail.com>
> Date: Tue, 28 Nov 2017 00:25:17 -0800
> Cc: 29465@debbugs.gnu.org, Eli Zaretskii <eliz@gnu.org>, rms@gnu.org
> 
> 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.

I think clarifying the prompt and adding an option is indeed the way
forward.

> 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 `?'?

Then the prompt should say that:

   Are you sure you want `*' and `?' to be passed to the shell?

> Since I was not confident that a good message could be written, I
> suggested removing the confirmation.

I think we should try to make the prompt more clear, it cannot be that
hard.  Removing the prompt will introduce backward incompatibility
with what Emacs was doing for the past 15 years, so it's a worse
alternative, IMO.

> 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.

You need to look up relevant discussions on Emacs mailing lists around
the date of the commit.  In this case, read this thread:

  http://lists.gnu.org/archive/html/emacs-devel/2002-01/msg00233.html

and also the original bug report and its followups:

  http://lists.gnu.org/archive/html/bug-gnu-emacs/2002-01/msg00230.html

> 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.

No, it was a bug report about a potentially risky feature, where a
user mistyping a command could have their files wiped out or cause
some other grave accident.

> However, it is now 15 years since; I don’t think there’s any value
> keeping the confirmation around for its original (?) purpose.

The syntax of the shell commands supported by dired-do-shell-command
and its features regarding '*' and '?' are still very complicated, as
they were back then.  Just the doc string describing the behavior is
so long it can scare.  So I don't see how the time that has passed is
of relevance here.





  reply	other threads:[~2017-11-28 16:26 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-27  7:16 bug#29465: 25.3; Confusing message for dired-do-shell-command substitution Allen Li
2017-11-27  7:34 ` Allen Li
2017-11-27  9:07   ` Michael Heerdegen
2017-11-27 15:58 ` Eli Zaretskii
2017-11-28  3:50   ` Tino Calancha
2017-11-28  8:25     ` Allen Li
2017-11-28 16:26       ` Eli Zaretskii [this message]
2017-11-28 20:13         ` Allen Li
2017-11-29  4:20           ` Drew Adams
2017-12-01  8:36             ` Eli Zaretskii
2017-12-02  6:31               ` Allen Li
2017-12-02  7:32                 ` Tino Calancha
2017-12-02  8:22                   ` Allen Li
2022-03-22 16:48                     ` Lars Ingebrigtsen
2017-11-28 16:15     ` Eli Zaretskii
     [not found] <<CAJr1M6f71vv2W090wPw8q_10wK=OwfgvMfM7DMiPn9G8oyY8AA@mail.gmail.com>
     [not found] ` <<83vahv67eb.fsf@gnu.org>
     [not found]   ` <<87fu8zukmb.fsf@gmail.com>
     [not found]     ` <<CAJr1M6cuB0RPcUfzsGHCGt+8m6-KH58FX4NoD==APb7dksrs2g@mail.gmail.com>
     [not found]       ` <<83609u5pyr.fsf@gnu.org>
     [not found]         ` <<CAJr1M6cT578dcFT4Uvg29===-q=7omx5DG+JSTuqczjO3paGgg@mail.gmail.com>
     [not found]           ` <<29b407d1-e1f6-4676-a686-ccdf19af8bb4@default>
     [not found]             ` <<83mv323kvx.fsf@gnu.org>
2017-12-01 15:42               ` Drew Adams

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83609u5pyr.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=29465@debbugs.gnu.org \
    --cc=tino.calancha@gmail.com \
    --cc=vianchielfaura@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.