bug#29465: 25.3; Confusing message for dired-do-shell-command substitution

[Eli Zaretskii]

> From: Allen Li <vianchielfaura@gmail.com>
> Date: Sun, 26 Nov 2017 23:16:59 -0800
> 
> When you use * or ? in dired-do-shell-command without the intent for
> Dired to replace it,  you are prompted with
> 
>   Confirm--do you mean to use `*' as a wildcard?
> 
> This message is confusing, because there are lots of ways for * to be
> passed to the shell without globbing.  I am also more familiar with
> the term globbing than wildcard, which makes it doubly confusing, for
> example if I run
> 
>   find ? -name '*.txt'
> 
> I get the message:
> 
>   Confirm--do you mean to use `*' as a wildcard?
> 
> What the question is really asking is, should * be passed to the shell
> directly, as whether or not it is interpreted as a glob is determined
> by the shell and the quoting rules in question.

Actually, AFAICT the command wants to ask this:

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

(as opposed to letting dired-do-shell-command interpret `*' as
described in the doc string).

> I think this confirmation message should be removed entirely.
> 
> 1. The edge case that it is trying to protect against is not very common.
> 2. There is no reasonable behavior that the user could expect from
> this edge case.
> 3. The documentation string clearly describes how * and ? are interpreted.
> 4. The confirmation message is not very informative and is possible 
> misleading.
> 5. This confirmation message shows up every time an advanced user
> wants to run any command containing * or ?, e.g. for find, grep, sed,
> or many other tools.
> 6. The confirmation message is not even shown consistently.  For
> example it is shown for
> 
>   find ? -name '*.txt'
> 
> but not for
> 
>   find * -name '*.txt'
> 
> Thus, it isn't even useful for protecting against some hypothetical
> unwanted behavior.

Tino added this confirmation last July, so I will let him defend his
change.

If we want to remove this confirmation, now is the time, because it
wasn't yet released with any Emacs version.  Once this confirmation is
out at large, it will be much harder to remove it, as that would be an
incompatible change.