unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#36331: 26.2; command run using dired-do-async-shell-command cannot take any input
@ 2019-06-22 12:37 Prof Jayanth R Varma
  2022-05-18 14:22 ` Lars Ingebrigtsen
  0 siblings, 1 reply; 7+ messages in thread
From: Prof Jayanth R Varma @ 2019-06-22 12:37 UTC (permalink / raw)
  To: 36331

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






^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#36331: 26.2; command run using dired-do-async-shell-command cannot take any input
  2019-06-22 12:37 bug#36331: 26.2; command run using dired-do-async-shell-command cannot take any input Prof Jayanth R Varma
@ 2022-05-18 14:22 ` Lars Ingebrigtsen
  2022-05-18 15:44   ` Eli Zaretskii
  0 siblings, 1 reply; 7+ messages in thread
From: Lars Ingebrigtsen @ 2022-05-18 14:22 UTC (permalink / raw)
  To: Prof Jayanth R Varma; +Cc: 36331

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





^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#36331: 26.2; command run using dired-do-async-shell-command cannot take any input
  2022-05-18 14:22 ` Lars Ingebrigtsen
@ 2022-05-18 15:44   ` Eli Zaretskii
  2022-05-19 23:36     ` Lars Ingebrigtsen
  0 siblings, 1 reply; 7+ messages in thread
From: Eli Zaretskii @ 2022-05-18 15:44 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: jrvarma, 36331

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





^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#36331: 26.2; command run using dired-do-async-shell-command cannot take any input
  2022-05-18 15:44   ` Eli Zaretskii
@ 2022-05-19 23:36     ` Lars Ingebrigtsen
  2022-05-20  3:32       ` Michael Heerdegen
  0 siblings, 1 reply; 7+ messages in thread
From: Lars Ingebrigtsen @ 2022-05-19 23:36 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: jrvarma, 36331

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





^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#36331: 26.2; command run using dired-do-async-shell-command cannot take any input
  2022-05-19 23:36     ` Lars Ingebrigtsen
@ 2022-05-20  3:32       ` Michael Heerdegen
  2022-05-20  8:37         ` Lars Ingebrigtsen
  0 siblings, 1 reply; 7+ messages in thread
From: Michael Heerdegen @ 2022-05-20  3:32 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: Eli Zaretskii, jrvarma, 36331

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.





^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#36331: 26.2; command run using dired-do-async-shell-command cannot take any input
  2022-05-20  3:32       ` Michael Heerdegen
@ 2022-05-20  8:37         ` Lars Ingebrigtsen
  2022-05-21  1:58           ` Michael Heerdegen
  0 siblings, 1 reply; 7+ messages in thread
From: Lars Ingebrigtsen @ 2022-05-20  8:37 UTC (permalink / raw)
  To: Michael Heerdegen; +Cc: Eli Zaretskii, jrvarma, 36331

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





^ permalink raw reply	[flat|nested] 7+ messages in thread

* bug#36331: 26.2; command run using dired-do-async-shell-command cannot take any input
  2022-05-20  8:37         ` Lars Ingebrigtsen
@ 2022-05-21  1:58           ` Michael Heerdegen
  0 siblings, 0 replies; 7+ messages in thread
From: Michael Heerdegen @ 2022-05-21  1:58 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: Eli Zaretskii, jrvarma, 36331

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.





^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2022-05-21  1:58 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-06-22 12:37 bug#36331: 26.2; command run using dired-do-async-shell-command cannot take any input Prof Jayanth R Varma
2022-05-18 14:22 ` Lars Ingebrigtsen
2022-05-18 15:44   ` Eli Zaretskii
2022-05-19 23:36     ` Lars Ingebrigtsen
2022-05-20  3:32       ` Michael Heerdegen
2022-05-20  8:37         ` Lars Ingebrigtsen
2022-05-21  1:58           ` Michael Heerdegen

Code repositories for project(s) associated with this inbox:

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).