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

[Allen Li]

On Mon, Nov 27, 2017 at 7:50 PM, Tino Calancha <tino.calancha@gmail.com> wrote:
> 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 ’*.txt’?  Or perhaps both?  What am I confirming exactly?

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 ’*.txt’ -o -name ’x??’
  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 ’*.txt’ -o -name ’x??’
  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’t think there’s any value keeping the
confirmation around for its original (?) purpose.