bug#48072: 28.0.50: dired-read-shell-command: handle empty input properly [PATCH]

[Boruch Baum <boruch_baum@gmx.com>]

On 2021-04-28 16:03, Eli Zaretskii wrote:
> > Date: Wed, 28 Apr 2021 08:49:52 -0400
> > From: Boruch Baum <boruch_baum@gmx.com>
> > Cc: kevin.legouguec@gmail.com, 48072@debbugs.gnu.org
> >
> > On 2021-04-28 14:58, Eli Zaretskii wrote:
> > > > Date: Wed, 28 Apr 2021 05:50:54 -0400
> > > > From: Boruch Baum <boruch_baum@gmx.com>
> > > > Cc: Eli Zaretskii <eliz@gnu.org>, 48072@debbugs.gnu.org
> > > >
> > > > I could restrict the check to the preparation of list of completion
> > > > candidates for the defaults put into the mini-buffer history (already
> > > > done in diredc, as an advice around function dired-guess-default), and
> > > > give dired users feedback when a command returns an error condition (on
> > > > this week's plan anyway).
> > >
> > > I'm not sure I understand what you are suggesting.  Do you mean set up
> > > the completion candidates so that they would only include executable
> > > files found on the system, but allow users also to type commands that
> > > are not among the completion candidates?  I think this could be
> > > confusing, and I don't think we have a precedent for such a behavior
> > > elsewhere.
> >
> > I don't understand what your point of confusion is, but it's your call,
> > of course. Your position has emacs offering users impossible choices,
> > choices guaranteed to fail.
>
> I'm asking you to help me understand the details of restricting the
> check that you are proposing.  Once I understand that, I could make up
> my mind about the proposal.  Right now I simply don't understand it.

You had that idea correct in your prior paragraph, where your wrote:

   "set up the completion candidates so that they would only include
   executable files found on the system, but allow users also to type
   commands that are not among the completion candidates"

What I can add is:

1) the completion candidates would be the subset of elements of the emacs
   variables `dired-guess-shell-alist-user' and
   `dired-guess-shell-alist-default' (diredc adds `diredc-shell-guess-fallback')
   which satisfy function `executable-find';

2) the user would face no constraint whatsoever in what could be entered.

2.1) I have mixed feelings about this, because for asynchronous operations
     any typographic error silently fails and yields a misleading message
     that can easily be interpreted as a successful completion.

2.1.1) Try the following in a vanilla dired buffer: Navigate POINT to a file,
       let's say 'bar', and press '&' for the async command. Then type in some
       garbage command, let's say 'foo', and <RET>. The response I get is a
       message in the mini-buffer: "foo bar&wait: finished." (BTW, I haven't
       figured out where that message is being generated; anyone's help would be
       appreciated; I would like to see if it can report errors).

2.1.2) It would be nice to get feedback from dired power users about how they
       use the '!' and '&' commands in practice. My experience and observation
       is that even power users use those commands for straightforward
       operations and use shell built-ins from either a shell buffer or a
       shell-script buffer. (note that some built-ins also have corresponding
       executables, eg '[').

2.1.3) My gut feeling is that everyone will appreciate getting feedback on an
       invalid command, and no-one would mind not being able to use shell
       built-ins. Thus, I prefer having the constraint.

2.2) The constraint as written only checks the initial atom of the command line,
     so it wouldn't catch "sort ? | uniqqq".

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0