|
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 AFAIK.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 youand 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.
[Prev in Thread] | Current Thread | [Next in Thread] |