[PATCH] run-command: Redirect stderr to a pipe before redirecting stdout to stderr

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 <redacted>
---
 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);
-		}

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

FWIW:

Acked-by: Johannes Sixt <redacted>

-- Hannes

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" <redacted>

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.

Christian Couder [off-list ref] wrote:

On Wed, 5 Mar 2008, I wrote:

quoted

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" <redacted>

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.