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

[Eli Zaretskii]

> Date: Wed, 28 Apr 2021 11:01:44 -0400
> From: Boruch Baum <boruch_baum@gmx.com>
> Cc: kevin.legouguec@gmail.com, 48072@debbugs.gnu.org
> 
> > > > 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.
> 
> 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"

Then I already stated my opinion about this above.  I wonder what do
others think about such a feature.

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

I think the message comes from process.c:status_notify, which is
called when the process is deleted after it exits.