[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Add facility to collect stderr of async subprocess

From: Tino Calancha
Subject: Re: [PATCH] Add facility to collect stderr of async subprocess
Date: Thu, 6 Oct 2016 18:13:29 +0900 (JST)
User-agent: Alpine 2.20 (DEB 67 2015-01-07)

On Thu, 6 Oct 2016, Eli Zaretskii wrote:

From: Tino Calancha <address@hidden>
Date: Thu, 6 Oct 2016 17:37:05 +0900 (JST)
Cc: address@hidden, Emacs developers <address@hidden>,
        address@hidden, Tino Calancha <address@hidden>

Actually, the need in this separation is rather rare.  Which is not
surprising, since running commands from a terminal by default delivers
both stdout and stderr to the screen, and the cases where these are
redirected separately are rare.
It depends of what the user is doing.  `shell-command' and
`async-shell-command' have being offering that since long time ago.

It is quite common redirect stderr from a shell: all shells allow that

My point is not about allowing it -- we definitely do.  My point is
about the importance of having this in every API.
If Michael is not ging to support it in remote i must agree with you
and say that is not important.
I'm saying that
this feature is relatively rarely needed, that's all.  How many times
did you need to redirect stderr separately from stdout in shell
commands you run from the shell prompt?
Honestly, not often.

We might modify the doc strings for shell-comamand and async-shell-command, following part:
In Elisp, you will often be better served by calling ‘start-process’
directly, since it offers more control and does not impose the use of a
shell (with its need to quote arguments).

I understand what Stefan means here with more control, but someone may argue that s-c and a-s-c allow the possibility to separate stdout from
stderr, which s-p does not.  That sounds like less control, at least
with respect the output.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]