GNU bug report logs - #28969
27.0.50; dired: Confirmation prompt for wildcard not surrounded by whitespace

Previous Next

Package: emacs;

Reported by: Michael Heerdegen <michael_heerdegen <at> web.de>

Date: Tue, 24 Oct 2017 16:42:02 UTC

Severity: normal

Tags: fixed, moreinfo, patch

Merged with 35564

Found in version 27.0.50

Fixed in version 28.1

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 28969 in the body.
You can then email your comments to 28969 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#28969; Package emacs. (Tue, 24 Oct 2017 16:42:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Michael Heerdegen <michael_heerdegen <at> web.de>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Tue, 24 Oct 2017 16:42:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: bug-gnu-emacs <at> gnu.org
Subject: 27.0.50;
 dired: Confirmation prompt for wildcard not surrounded by whitespace
Date: Tue, 24 Oct 2017 18:40:54 +0200
Hello,

the docstring of `dired-do-shell-command' says:

| `*' and `?' when not surrounded by whitespace nor `\\=`' have no special
| significance for `dired-do-shell-command', and are passed through
| normally to the shell, but you must confirm first.

However, the `y-or-n-p' prompts asks:

  "Confirm--do you mean to use `*' as a wildcard? "

and

  "Confirm--do you mean to use `?' as a wildcard? "

and you must answer with 'y' to let these not be treated as wildcards -
if you answer with 'n' as the docstring suggests, the operation is
aborted.  So, with other words, I think the questions must be inverted.

A simple test case is to create a symlink 1*1 -> xedit and to try to
open some textfile with "1*1".


TIA,

Michael.


In GNU Emacs 27.0.50 (build 3, x86_64-pc-linux-gnu, GTK+ Version 3.22.24)
 of 2017-10-19 built on drachen
Repository revision: 658853aebb0ae2ee243276e04a7672fa7525ec5c
Windowing system distributor 'The X.Org Foundation', version 11.0.11905000
System Description:	Debian GNU/Linux testing (buster)





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#28969; Package emacs. (Sun, 14 Jul 2019 21:24:01 GMT) Full text and rfc822 format available.

Message #8 received at 28969 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: 28969 <at> debbugs.gnu.org
Subject: Re: bug#28969: 27.0.50; dired: Confirmation prompt for wildcard not
 surrounded by whitespace
Date: Sun, 14 Jul 2019 23:23:20 +0200
Michael Heerdegen <michael_heerdegen <at> web.de> writes:

> the docstring of `dired-do-shell-command' says:
>
> | `*' and `?' when not surrounded by whitespace nor `\\=`' have no special
> | significance for `dired-do-shell-command', and are passed through
> | normally to the shell, but you must confirm first.
>
> However, the `y-or-n-p' prompts asks:
>
>   "Confirm--do you mean to use `*' as a wildcard? "
>
> and
>
>   "Confirm--do you mean to use `?' as a wildcard? "
>
> and you must answer with 'y' to let these not be treated as wildcards -
> if you answer with 'n' as the docstring suggests, the operation is
> aborted.  So, with other words, I think the questions must be inverted.

Hm...  I don't quite follow you here...  It says it has no significance
for the command, but just passes it through to the shell.  Where, of
course, it has great significance.

If you create the file 1-1, put "bar" in it, and say "! cat 1*1" on the
file, after you've answered "y", you'll get a buffer with "bar bar" in
it.

So I think all this is correct?  Unless I'm misreading you.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#28969; Package emacs. (Sun, 14 Jul 2019 22:39:01 GMT) Full text and rfc822 format available.

Message #11 received at 28969 <at> debbugs.gnu.org (full text, mbox):

From: Noam Postavsky <npostavs <at> gmail.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Michael Heerdegen <michael_heerdegen <at> web.de>, 28969 <at> debbugs.gnu.org
Subject: Re: bug#28969: 27.0.50;
 dired: Confirmation prompt for wildcard not surrounded by whitespace
Date: Sun, 14 Jul 2019 18:38:01 -0400
merge 28969 35564
quit

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> Michael Heerdegen <michael_heerdegen <at> web.de> writes:
>
>> the docstring of `dired-do-shell-command' says:
>>
>> | `*' and `?' when not surrounded by whitespace nor `\\=`' have no special
>> | significance for `dired-do-shell-command', and are passed through
>> | normally to the shell, but you must confirm first.
>>
>> However, the `y-or-n-p' prompts asks:
>>
>>   "Confirm--do you mean to use `*' as a wildcard? "
>>
>> and
>>
>>   "Confirm--do you mean to use `?' as a wildcard? "
>>
>> and you must answer with 'y' to let these not be treated as wildcards -
>> if you answer with 'n' as the docstring suggests, the operation is
>> aborted.  So, with other words, I think the questions must be inverted.
>
> Hm...  I don't quite follow you here...  It says it has no significance
> for the command, but just passes it through to the shell.  Where, of
> course, it has great significance.
>
> If you create the file 1-1, put "bar" in it, and say "! cat 1*1" on the
> file, after you've answered "y", you'll get a buffer with "bar bar" in
> it.
>
> So I think all this is correct?  Unless I'm misreading you.

The meaning of "wildcard" is a bit ambiguous in the prompt itself.
There is another report about this in #35564, and patches to greatly
enhance the prompt.

https://debbugs.gnu.org/35564#104




Merged 28969 35564. Request was from Noam Postavsky <npostavs <at> gmail.com> to control <at> debbugs.gnu.org. (Sun, 14 Jul 2019 22:39:02 GMT) Full text and rfc822 format available.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#28969; Package emacs. (Mon, 15 Jul 2019 01:35:02 GMT) Full text and rfc822 format available.

Message #16 received at 28969 <at> debbugs.gnu.org (full text, mbox):

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 28969 <at> debbugs.gnu.org
Subject: Re: bug#28969: 27.0.50; dired: Confirmation prompt for wildcard not
 surrounded by whitespace
Date: Mon, 15 Jul 2019 03:34:16 +0200
Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> > | `*' and `?' when not surrounded by whitespace nor `\\=`' have no special
> > | significance for `dired-do-shell-command', and are passed through
> > | normally to the shell, but you must confirm first.
> >
> > However, the `y-or-n-p' prompts asks:
> >
> >   "Confirm--do you mean to use `*' as a wildcard? "
> >
> > and
> >
> >   "Confirm--do you mean to use `?' as a wildcard? "
> >
> > and you must answer with 'y' to let these not be treated as wildcards -
> > if you answer with 'n' as the docstring suggests, the operation is
> > aborted.  So, with other words, I think the questions must be inverted.
>
> Hm...  I don't quite follow you here...  It says it has no significance
> for the command, but just passes it through to the shell.  Where, of
> course, it has great significance.

The docstring is good I think, but the questions are bad IMHO.  First
it's not clear if "wildcard" is meant with respect to the command or to
the shell (this is answered by the doc, yes, still, you have to remember
it), and second, it depends on the concrete command string if the shell
would interpret * or ? as a wildcard at all.  In my example (in my
initial report), also the shell did not interpret it as wildcard, but I
had to say "y" to get it executed.  This is very confusing.  It would be
better to ask "confirm - pass literal `*' to the shell?" or so.

BTW, I had several use cases where * or ?, don't remember, was not
isolated, and I wanted to answer "n" to still get the substitution by
the command and was disappointed that Emacs just canceled.  Maybe one of
the suggested patches also improves that, I haven't checked yet.

Michael.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#28969; Package emacs. (Mon, 15 Jul 2019 19:20:02 GMT) Full text and rfc822 format available.

Message #19 received at 28969 <at> debbugs.gnu.org (full text, mbox):

From: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 28969 <at> debbugs.gnu.org,
 Noam Postavsky <npostavs <at> gmail.com>, Drew Adams <drew.adams <at> oracle.com>
Subject: Re: bug#28969: 27.0.50;
 dired: Confirmation prompt for wildcard not surrounded by whitespace
Date: Mon, 15 Jul 2019 21:19:05 +0200
[Message part 1 (text/plain, inline)]
Michael Heerdegen <michael_heerdegen <at> web.de> writes:

> In my example (in my
> initial report), also the shell did not interpret it as wildcard, but I
> had to say "y" to get it executed.  This is very confusing.  It would be
> better to ask "confirm - pass literal `*' to the shell?" or so.

Yup, that's what I set out to do in bug#35564.  Here is the patch
series, condensed into a single patch for convenience.

[0001-Tweak-dired-warning-about-wildcard-characters.patch (text/x-patch, attachment)]
[Message part 3 (text/plain, inline)]
It is a bit more involved than a simple rewording, mainly because I
could not find a concise sentence that sounded 100%-unambiguous
(e.g. "literal" might be taken to mean "suitably backslash-escaped or
quoted").

> BTW, I had several use cases where * or ?, don't remember, was not
> isolated, and I wanted to answer "n" to still get the substitution by
> the command and was disappointed that Emacs just canceled.  Maybe one of
> the suggested patches also improves that, I haven't checked yet.

Allowing the user to substitute non-isolated characters is something
Drew also suggested in bug#35564.

I haven't tackled that yet (haven't met the use-case).  What would a
good UI look like?  Successive prompting for each non-isolated
character?  Something like:

> Substitute highlighted occurrence of `?'? ([y]es, [n]o, [a]bort)

Although note that you can already tell Dired that your '?' is meant to
be substituted, by surrounding it with backquotes.  E.g. try to mark
some files, then

    ! echo 'foo`?`bar'

It's not implemented for '*' though.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#28969; Package emacs. (Mon, 15 Jul 2019 20:51:02 GMT) Full text and rfc822 format available.

Message #22 received at 28969 <at> debbugs.gnu.org (full text, mbox):

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 28969 <at> debbugs.gnu.org,
 Noam Postavsky <npostavs <at> gmail.com>, Drew Adams <drew.adams <at> oracle.com>
Subject: Re: bug#28969: 27.0.50; dired: Confirmation prompt for wildcard not
 surrounded by whitespace
Date: Mon, 15 Jul 2019 22:50:12 +0200
Kévin Le Gouguec <kevin.legouguec <at> gmail.com> writes:

> Yup, that's what I set out to do in bug#35564.  Here is the patch
> series, condensed into a single patch for convenience.

Ok, will try it.

> Although note that you can already tell Dired that your '?' is meant to
> be substituted, by surrounding it with backquotes.  E.g. try to mark
> some files, then
>
>     ! echo 'foo`?`bar'

Maybe this is already enough.

> It's not implemented for '*' though.

Dunno if that has use cases.


BTW, in the docstring of `dired-do-shell-command',

(1) In this sentence:

| `*' and `?' when not surrounded by whitespace nor ``' have no special

can we avoid that ` gets linked to the backquote macro?

And

(2) "If you want to use `*' as a shell wildcard with whitespace around
it, write `*\"\"' in place of just `*'."

does that really mean *"" or rather "*"?

Michael.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#28969; Package emacs. (Tue, 16 Jul 2019 05:54:01 GMT) Full text and rfc822 format available.

Message #25 received at 28969 <at> debbugs.gnu.org (full text, mbox):

From: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 28969 <at> debbugs.gnu.org,
 Noam Postavsky <npostavs <at> gmail.com>, Drew Adams <drew.adams <at> oracle.com>
Subject: Re: bug#28969: 27.0.50;
 dired: Confirmation prompt for wildcard not surrounded by whitespace
Date: Tue, 16 Jul 2019 07:53:09 +0200
Michael Heerdegen <michael_heerdegen <at> web.de> writes:

> BTW, in the docstring of `dired-do-shell-command',
>
> (1) In this sentence:
>
> | `*' and `?' when not surrounded by whitespace nor ``' have no special
>
> can we avoid that ` gets linked to the backquote macro?

No idea how to fix that off the top of my head.

> (2) "If you want to use `*' as a shell wildcard with whitespace around
> it, write `*\"\"' in place of just `*'."
>
> does that really mean *"" or rather "*"?

I think it really means *"".  From some quick testing in a Dired buffer:

    M-! touch foo bar baz RET
    g                           ; Assuming point is now on "bar"
    ! echo quux "*" corge RET y ; ⇒ quux * corge bar
    ! echo quux *"" corge RET y ; ⇒ quux bar baz foo corge bar

*'' also works.  AFAICT it's a way to work around Dired's isolation
detection (* is not surrounded with spaces, so it's not isolated) while
exploiting the fact that the quoted empty string will disappear once
"expanded" by the shell.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#28969; Package emacs. (Thu, 10 Oct 2019 18:46:01 GMT) Full text and rfc822 format available.

Message #28 received at 28969 <at> debbugs.gnu.org (full text, mbox):

From: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
To: 35564 <at> debbugs.gnu.org
Cc: Michael Heerdegen <michael_heerdegen <at> web.de>,
 Noam Postavsky <npostavs <at> gmail.com>, Juri Linkov <juri <at> linkov.net>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>, Eli Zaretskii <eliz <at> gnu.org>,
 28969 <at> debbugs.gnu.org, Drew Adams <drew.adams <at> oracle.com>
Subject: bug#35564: [PATCH v5] Tweak dired warning about "wildcard" characters
Date: Thu, 10 Oct 2019 20:45:14 +0200
[Message part 1 (text/plain, inline)]
Finally got around to try out rmc.el.

A brief recap of the issue: dired-do-shell-command looks out for any
non-isolated metacharacters[1], and prompts the user when it finds some.
The problem is that the prompt is downright misleading under some
circumstances.  E.g. after marking some files in a Dired buffer:

    ! sed 's/?/!/g' RET
    => Confirm--do you mean to use `?' as a wildcard?

The answer a user must input to proceed is "yes", despite '?' not being
a wildcard in this situation; the answer some users may give intuitively
is "no" (or, in my case, "whaaa?").


This patch series initially tried to shove the command in the prompt,
highlight the non-isolated characters, and re-phrase the prompt to be
more accurate (i.e. not talk about wildcards).

It went through a several iterations for a few reasons[2]; most recently
Michael suggested using read-multiple-choice [bug#35564#136]; I looked
at how nsm.el uses it, saw that is was good, and got distracted for two
months.

Here is the new series:

[0001-Tweak-dired-warning-about-wildcard-characters.patch (text/x-patch, attachment)]
[0002-Dedup-dired-aux-isolated-char-searching-Bug-35564.patch (text/x-patch, attachment)]
[0003-Add-markers-below-non-isolated-chars-in-dired-prompt.patch (text/x-patch, attachment)]
[0004-Simplify-highlighting-assertions.patch (text/x-patch, attachment)]
[0005-Hide-detailed-explanations-in-a-togglable-help-buffe.patch (text/x-patch, attachment)]
[Message part 7 (text/plain, inline)]
Highlights:

- removed the patch for y-or-n-p, since we don't need it anymore,
- (squashed Noam's patch with my fixups,)
- the last patch contains the new stuff:
    - the default prompt is now as concise as the old one,
    - pressing 'd' toggles a help buffer which highlights occurrences
      using the warning face,
    - when the help buffer is enabled, pressing 'm' toggles the '^'
      markers.

Squashed patch for convenience:

[0001-Tweak-dired-warning-about-wildcard-characters.patch (text/x-patch, attachment)]
[Message part 9 (text/plain, inline)]
To try the changes out, it's enough to reload dired-aux.el, mark a few
files in Dired, type e.g.

    ! sed 's/?/!/g' RET

… and play with the new prompt.

Let me know if this UI looks OK, and how the implementation may be
improved.  Thank you for your patience.


Not addressed in this patch series:

- letting the user iterate over non-isolated occurrences and
  selectively substitute them,
- allowing '*' to be substituted when surrounded by backquotes, just
  like '?'.

I do find these features valuable (or at least worthy of discussion),
however the current bug reports were motivated merely by an inaccurate
warning; I'd like to close this first before considering further
changes.


[1] '?' when not surrounded by whitespace or backquotes,
    '*' when not surrounded by whitespace.

[2] Trying to find the right balance between concision and accurate
    explanation, considering that some users may not know about the
    file-substitution feature; also trying to make the highlighting
    "accessible", i.e. not just relying on colored faces.

Added tag(s) moreinfo. Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Sun, 20 Sep 2020 11:44:02 GMT) Full text and rfc822 format available.

Added tag(s) fixed. Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Sun, 20 Sep 2020 12:19:02 GMT) Full text and rfc822 format available.

bug marked as fixed in version 28.1, send any further explanations to 35564 <at> debbugs.gnu.org and Kévin Le Gouguec <kevin.legouguec <at> gmail.com> Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Sun, 20 Sep 2020 12:19:03 GMT) Full text and rfc822 format available.

bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Mon, 19 Oct 2020 11:24:07 GMT) Full text and rfc822 format available.

This bug report was last modified 3 years and 183 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.