# [PATCH] run-command: Redirect stderr to a pipe before redirecting stdout to stderr 5 messages from 2008-03-05 to 2008-03-06. Participants: Christian Couder, Johannes Sixt, Xavier Maillard, Shawn O. Pearce. Thread: https://gitlist.dev/t/12510 ## Christian Couder, 2008-03-05 07:35 Subject: [PATCH] run-command: Redirect stderr to a pipe before redirecting stdout to stderr Message-ID: <20080305083516.e1a2a139.chriscool@tuxfamily.org> URL: https://gitlist.dev/e/20080305083516.e1a2a139.chriscool%40tuxfamily.org ``` With this patch, in the 'start_command' function after forking we now take care of stderr in the child process before stdout. This way if 'start_command' is called with a 'child_process' argument like this: .err = -1; .stdout_to_stderr = 1; then stderr will be redirected to a pipe before stdout is redirected to stderr. So we can now get the process' stdout from the pipe (as well as its stderr). Earlier such a call would have redirected stdout to stderr before stderr was itself redirected, and therefore stdout would not have followed stderr, which would not have been very useful anyway. Update documentation in 'api-run-command.txt' accordingly. Signed-off-by: Christian Couder --- Documentation/technical/api-run-command.txt | 7 ++++--- run-command.c | 14 +++++++------- 2 files changed, 11 insertions(+), 10 deletions(-) Changes since previous version: - improved patch justification as requested by Junio, - s/before/after/ in 'api-run-command.txt' (ooops). diff --git a/Documentation/technical/api-run-command.txt b/Documentation/technical/api-run-command.txt index fde3b45..c364a22 100644 --- a/Documentation/technical/api-run-command.txt +++ b/Documentation/technical/api-run-command.txt @@ -111,9 +111,10 @@ stderr as follows: .no_stdin, .no_stdout, .no_stderr: The respective channel is redirected to /dev/null. - .stdout_to_stderr: stdout of the child is redirected to the - parent's stderr (i.e. *not* to what .err or - .no_stderr specify). + .stdout_to_stderr: stdout of the child is redirected to its + stderr. This happens after stderr is itself redirected. + So stdout will follow stderr to wherever it is + redirected. To modify the environment of the sub-process, specify an array of string pointers (NULL terminated) in .env: diff --git a/run-command.c b/run-command.c index 743757c..44100a7 100644 --- a/run-command.c +++ b/run-command.c @@ -91,6 +91,13 @@ int start_command(struct child_process *cmd) close(cmd->in); } + if (cmd->no_stderr) + dup_devnull(2); + else if (need_err) { + dup2(fderr[1], 2); + close_pair(fderr); + } + if (cmd->no_stdout) dup_devnull(1); else if (cmd->stdout_to_stderr) @@ -103,13 +110,6 @@ int start_command(struct child_process *cmd) close(cmd->out); } - if (cmd->no_stderr) - dup_devnull(2); - else if (need_err) { - dup2(fderr[1], 2); - close_pair(fderr); - } ``` ## Johannes Sixt, 2008-03-05 07:36 Subject: Re: [PATCH] run-command: Redirect stderr to a pipe before redirecting stdout to stderr Message-ID: <47CE4D73.4050607@viscovery.net> URL: https://gitlist.dev/e/47CE4D73.4050607%40viscovery.net In-Reply-To: <20080305083516.e1a2a139.chriscool@tuxfamily.org> ``` Christian Couder schrieb: > With this patch, in the 'start_command' function after forking > we now take care of stderr in the child process before stdout. > > This way if 'start_command' is called with a 'child_process' > argument like this: > > .err = -1; > .stdout_to_stderr = 1; > > then stderr will be redirected to a pipe before stdout is > redirected to stderr. So we can now get the process' stdout > from the pipe (as well as its stderr). > > Earlier such a call would have redirected stdout to stderr > before stderr was itself redirected, and therefore stdout > would not have followed stderr, which would not have been > very useful anyway. > > Update documentation in 'api-run-command.txt' accordingly. > > Signed-off-by: Christian Couder FWIW: Acked-by: Johannes Sixt -- Hannes ``` ## Xavier Maillard, 2008-03-06 01:00 Subject: Re: [PATCH] run-command: Redirect stderr to a pipe before redirecting stdout to stderr Message-ID: <200803060100.m26104Vx004182@localhost.localdomain> URL: https://gitlist.dev/e/200803060100.m26104Vx004182%40localhost.localdomain In-Reply-To: <20080305083516.e1a2a139.chriscool@tuxfamily.org> ``` Signed-off-by: Christian Couder Tested successfully. Acked-by: Xavier Maillard Xavier -- http://www.gnu.org http://www.april.org http://www.lolica.org ``` ## Christian Couder, 2008-03-06 05:44 Subject: Re: [PATCH] run-command: Redirect stderr to a pipe before redirecting stdout to stderr Message-ID: <20080306064415.c5ca762a.chriscool@tuxfamily.org> URL: https://gitlist.dev/e/20080306064415.c5ca762a.chriscool%40tuxfamily.org In-Reply-To: <20080305083516.e1a2a139.chriscool@tuxfamily.org> ``` Hi Junio and Shawn, On Wed, 5 Mar 2008, I wrote: > With this patch, in the 'start_command' function after forking > we now take care of stderr in the child process before stdout. > ... I am afraid I forgot the From: "Shawn O. Pearce" at the top of the patch in my last resend, so the patch was attributed to me instead of Shawn. Is it possible to do something about it ? (I fear not since it is now in 'next' but maybe I am wrong.) Thanks in advance, Christian. ``` ## Shawn O. Pearce, 2008-03-06 06:42 Subject: Re: [PATCH] run-command: Redirect stderr to a pipe before redirecting stdout to stderr Message-ID: <20080306064225.GS8410@spearce.org> URL: https://gitlist.dev/e/20080306064225.GS8410%40spearce.org In-Reply-To: <20080306064415.c5ca762a.chriscool@tuxfamily.org> ``` Christian Couder wrote: > On Wed, 5 Mar 2008, I wrote: > > With this patch, in the 'start_command' function after forking > > we now take care of stderr in the child process before stdout. > > ... > > I am afraid I forgot the > > From: "Shawn O. Pearce" > > at the top of the patch in my last resend, so the patch was attributed to me instead of Shawn. > > Is it possible to do something about it ? (I fear not since it is now in 'next' but maybe I am wrong.) Nope, its done and over with. Don't sweat it. It was a very short patch, you wrote it apparently independently from me, so the author line from you is just as valid. I say its fine as is. Maybe better. Your version had an API doc update. My version is what triggered the "maybe we should document the API before we modify it further" discussion. ;-) -- Shawn. ```