bug#36331: 26.2; command run using dired-do-async-shell-command cannot take any input

bug#36331: 26.2; command run using dired-do-async-shell-command cannot take any input

[Prof Jayanth R Varma]

dired-do-async-shell-command in dired-aux.el runs the command dired-shell-stuff-it which adds "&wait" to the command line. The source code explains the logic as follows:

                    ;; POSIX shells running a list of commands in the background
                    ;; (LIST = cmd_1 & [cmd_2 & ... cmd_i & ... cmd_N &])
                    ;; return once cmd_N ends, i.e., the shell does not
                    ;; wait for cmd_i to finish before executing cmd_i+1.
                    ;; That means, running (shell-command LIST) may not show
                    ;; the output of all the commands (Bug#23206).
                    ;; Add 'wait' to force those POSIX shells to wait until
                    ;; all commands finish.
                    (or (and parallel-in-background (not w32-shell)
                             "&wait")
                        "")))
Unfortunately, "parallel-in-background" is true even if there is only one command to be run (because there is only one selected file) as long as the command does not contain the character "*":

               (sequentially (string-match "[ \t]*;[ \t]*\\'" command))
               (parallel-in-background
                    (and in-background (not sequentially) (not (eq system-type 'ms-dos))))

As a result, the original single command now becomes a background command (by the addition of "& wait") and it loses access to standard input (it is implicitly run with an empty standard input). If the command asks for a confirmation prompt or a password, there is no way to provide that input. A simple though somewhat silly way to demonstrate the problem is by comparing the following two commands run using dired-do-async-shell-command on a single selected file (say 1.txt)

First command with "*" in the command line works as expected

       cat - * >2.txt

With this command, the *Async Shell Command* buffer waits for us to type in whatever lines that we want. When we terminate the input with Control-D (EOF), the command concatenates the inputs lines with 1.txt and writes the result to 2.txt.

Second command without "*" in the command line does NOT work as expected

       cat - >2.txt

With this command, the command runs without waiting for any input, and simply copies 1.txt to 2.txt because standard input is implicitly empty.

My suggestion is that the definition of "parallel-in-background" in dired-shell-stuff-it should include an additional test that the variable "file-list" contains more than one file.

-----------------------------------------------------

In GNU Emacs 26.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.8)
 of 2019-04-12 built on juergen
Windowing system distributor 'The X.Org Foundation', version 11.0.12005000
Configured using:
 'configure --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib
 --localstatedir=/var --with-x-toolkit=gtk3 --with-xft --with-modules
 'CFLAGS=-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong
 -fno-plt' CPPFLAGS=-D_FORTIFY_SOURCE=2
 LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now'

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GSETTINGS GLIB
NOTIFY ACL GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM MODULES THREADS LIBSYSTEMD LCMS2

Important settings:
  value of $LC_COLLATE: en_US.utf8
  value of $LC_MONETARY: en_IN.UTF-8
  value of $LC_NUMERIC: en_IN.UTF-8
  value of $LC_TIME: en_IN.UTF-8
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

bug#36331: 26.2; command run using dired-do-async-shell-command cannot take any input

[Lars Ingebrigtsen]

Prof Jayanth R Varma <jrvarma@gmail.com> writes:

> As a result, the original single command now becomes a background
> command (by the addition of "& wait") and it loses access to standard
> input (it is implicitly run with an empty standard input). If the
> command asks for a confirmation prompt or a password, there is no way
> to provide that input. A simple though somewhat silly way to
> demonstrate the problem is by comparing the following two commands run
> using dired-do-async-shell-command on a single selected file (say
> 1.txt)
>
> First command with "*" in the command line works as expected
>
>        cat - * >2.txt
>
> With this command, the *Async Shell Command* buffer waits for us to
> type in whatever lines that we want. When we terminate the input with
> Control-D (EOF), the command concatenates the inputs lines with 1.txt
> and writes the result to 2.txt.

(I'm going through old bug reports that unfortunately weren't resolved
at the time.)

I can reproduce this, but I think that this works is more by accident
than by design.  I don't think the `&' command is supposed to allow any
input to the command -- at least it's not documented to.

In this example, you can type in stuff in the *Async Shell Command*
buffer, and it'll append to 2.txt what you're typing, which is pretty
eccentric behaviour for this command.

Does anybody know whether this was intended?

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

bug#36331: 26.2; command run using dired-do-async-shell-command cannot take any input

[Eli Zaretskii]

> Cc: 36331@debbugs.gnu.org
> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Wed, 18 May 2022 16:22:59 +0200
> 
> > First command with "*" in the command line works as expected
> >
> >        cat - * >2.txt
> >
> > With this command, the *Async Shell Command* buffer waits for us to
> > type in whatever lines that we want. When we terminate the input with
> > Control-D (EOF), the command concatenates the inputs lines with 1.txt
> > and writes the result to 2.txt.
> 
> (I'm going through old bug reports that unfortunately weren't resolved
> at the time.)
> 
> I can reproduce this, but I think that this works is more by accident
> than by design.  I don't think the `&' command is supposed to allow any
> input to the command -- at least it's not documented to.

Indeed, asynchronous commands cannot rely on being able to read and
write standard streams.  Interactive commands should not be run
asynchronously.

bug#36331: 26.2; command run using dired-do-async-shell-command cannot take any input

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> Indeed, asynchronous commands cannot rely on being able to read and
> write standard streams.  Interactive commands should not be run
> asynchronously.

So I've now changed the command here to be consistent -- never accept
input (and mentioned this in the doc string for `&').

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

bug#36331: 26.2; command run using dired-do-async-shell-command cannot take any input

[Michael Heerdegen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> So I've now changed the command here to be consistent -- never accept
> input (and mentioned this in the doc string for `&').

Sorry if this is a stupid question - but that change seems to make this:

  (require 'dired-aux)
  (dired-do-async-shell-command "xedit" nil '("~/.bashrc"))

behave as if the shell command was executed synchronously (try emacs
-Q).  Is this intended?

TIA,

Michael.

bug#36331: 26.2; command run using dired-do-async-shell-command cannot take any input

[Lars Ingebrigtsen]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> Sorry if this is a stupid question - but that change seems to make this:
>
>   (require 'dired-aux)
>   (dired-do-async-shell-command "xedit" nil '("~/.bashrc"))
>
> behave as if the shell command was executed synchronously (try emacs
> -Q).  Is this intended?

Oops; indeed not.  I misread the code and put the &wait in the wrong
place.  Should be fixed now; thanks.

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

bug#36331: 26.2; command run using dired-do-async-shell-command cannot take any input

[Michael Heerdegen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Oops; indeed not.  I misread the code and put the &wait in the wrong
> place.  Should be fixed now; thanks.

Yep - looks good.

Thanks,

Michael.