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

Previous Next

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

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

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

From: Prof Jayanth R Varma <jrvarma <at> gmail.com> 
To: bug-gnu-emacs <at> gnu.org
Subject: 26.2;
 command run using dired-do-async-shell-command cannot take any input
Date: Sat, 22 Jun 2019 18:07:59 +0530

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

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Prof Jayanth R Varma <jrvarma <at> gmail.com>
Cc: 36331 <at> debbugs.gnu.org
Subject: Re: bug#36331: 26.2; command run using dired-do-async-shell-command
 cannot take any input
Date: Wed, 18 May 2022 16:22:59 +0200

Prof Jayanth R Varma <jrvarma <at> 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

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: jrvarma <at> gmail.com, 36331 <at> debbugs.gnu.org
Subject: Re: bug#36331: 26.2;
 command run using dired-do-async-shell-command cannot take any input
Date: Wed, 18 May 2022 18:44:24 +0300

> Cc: 36331 <at> debbugs.gnu.org
> From: Lars Ingebrigtsen <larsi <at> 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.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: jrvarma <at> gmail.com, 36331 <at> debbugs.gnu.org
Subject: Re: bug#36331: 26.2; command run using dired-do-async-shell-command
 cannot take any input
Date: Fri, 20 May 2022 01:36:34 +0200

Eli Zaretskii <eliz <at> 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

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

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, jrvarma <at> gmail.com, 36331 <at> debbugs.gnu.org
Subject: Re: bug#36331: 26.2; command run using dired-do-async-shell-command
 cannot take any input
Date: Fri, 20 May 2022 05:32:29 +0200

Lars Ingebrigtsen <larsi <at> 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.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: Eli Zaretskii <eliz <at> gnu.org>, jrvarma <at> gmail.com, 36331 <at> debbugs.gnu.org
Subject: Re: bug#36331: 26.2; command run using dired-do-async-shell-command
 cannot take any input
Date: Fri, 20 May 2022 10:37:52 +0200

Michael Heerdegen <michael_heerdegen <at> 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

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

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, jrvarma <at> gmail.com, 36331 <at> debbugs.gnu.org
Subject: Re: bug#36331: 26.2; command run using dired-do-async-shell-command
 cannot take any input
Date: Sat, 21 May 2022 03:58:36 +0200

Lars Ingebrigtsen <larsi <at> 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.

Previous Next

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