GNU bug report logs - #56745
Cannot forward process output to both stdout and stderr (in batch mode)

Previous Next

Package: emacs;

Reported by: Paul Pogonyshev <pogonyshev <at> gmail.com>

Date: Sun, 24 Jul 2022 16:28:02 UTC

Severity: normal

To reply to this bug, email your comments to 56745 AT debbugs.gnu.org.

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

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#56745; Package emacs. (Sun, 24 Jul 2022 16:28:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Paul Pogonyshev <pogonyshev <at> gmail.com>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Sun, 24 Jul 2022 16:28:02 GMT) Full text and rfc822 format available.

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

From: Paul Pogonyshev <pogonyshev <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Cannot forward process output to both stdout and stderr (in batch
 mode)
Date: Sun, 24 Jul 2022 18:27:32 +0200
[Message part 1 (text/plain, inline)]
Especially in batch mode it is often useful to run an external process,
letting it write to stdout and stderr as if it was the main executed
process. As far as I see (and I have spent quite a lot of time
investigating this), with Emacs it is not possible.

I found two options for stdout+stderr, but with neither allowing me to
achieve quite what I want.

1. You can run a process with stdout and stderr combined, then use e.g.
process filter function to e.g. `princ' received output. The disadvantage
is that stdout and stderr get bunched together. For example, if someone
runs your script with `> /dev/null', he will also miss stderr output of the
child process. Perhaps even more importantly, robust automated processing
of output becomes impossible, as it can contain "garbage", i.e. output
meant for stderr.

2. You can split stdout and stderr e.g. by using `make-pipe-process' for
stderr and then e.g. use `princ' in the filter for the "real" process (only
stdout output) and `message' for stderr process. The problem is that here
output comes completely unsynchronized and (at least usually) in larger
chunks. If the child process intermixes stdout and stderr output, it comes
out not in the original order. You also lose interactivity if the child
process e.g. runs for minutes and prints progress messages regularly during
that time.

In comparison, with Python (or pretty much any other "real" language) this
is trivial, see attached `output-forwarder.py'. I don't see a way to
replicate these three lines in Elisp.

It would be nice if e.g. `make-process' grew an argument `:forward'
(possible values `t', `stderr' and `stdout'; the latter to forward only one
stream). It would be fine if this was incompatible with `:buffer' and
`:stderr', i.e. if this couldn't be specified together with those options.
I wouldn't mind any other interface either, as long as it worked.

Attachments:
* `mixed-output.py': a simple Python scripts that writes to both stdout and
stderr with small delays;
* `output-forwarder.py': a simple Python scripts that runs whatever command
is specified on the command line and forwards it output cleanly; usage,
e.g.: `$ ./output-forwarder.py ./mixed-output.py' or `$
./output-forwarder.py ./mixed-output.py >/dev/null'.

Paul
[Message part 2 (text/html, inline)]
[mixed-output.py (text/x-python, attachment)]
[output-forwarder.py (text/x-python, attachment)]

This bug report was last modified 1 year and 269 days ago.

Previous Next


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