From: Brian Candler <B.Candler@...>
Date: 2003-05-11T17:21:14+09:00
Subject: Re: RCR for child execution

On Sun, May 11, 2003 at 09:29:43AM +0900, Simon Strandgaard wrote:
> > On Sun, May 11, 2003 at 01:27:31AM +0900, Simon Strandgaard wrote:
> >> Ruby-child-processes inherit stdout/stderr,  not rb_stdout, rb_stderr.
> >> From C/C++ I cannot use stdout/stderr.  
> > 
> > What do you mean, "from C/C++ I cannot use stdout/stderr"??
> 
> Everything is OK when your application starts up, stdout/stderr works
> fine. Then you initialize ruby and redirects its output elsewhere.
> Now stdout/stderr doesn't work any longer.

Right. Ruby's STDOUT *is* your C++ application's stdout, and Ruby's STDERR
*is* your C++ application's stderr. That's because your application is your
application! The fact that it is written half in one language and half in
another is beside the point; at the end of the day it's a single application
which runs under an O/S.

Tinkering with STDOUT in Ruby changes the 'real' underlying stdout, and
that's what a fork/exec child shares with you unless you pass it something
else.

Now, when you do "puts" there is a layer of indirection because it writes to
$defout, which you can point elsewhere without touching stdout, but there's
nothing like that for stderr: any Ruby-generated warnings go directly to
stderr, and any Ruby code which says
            $stderr.puts("my warning")
clearly does the same.

But that's an aside, as it's not relevant to fork/exec children: if you have
changed $defout then the child won't know, as the only thing it sees is the
O/S level stdout and stderr. You can open them as different files/pipes
after the fork and before the exec, or you can leave them alone, in which
case they are shared.

> I tried restoring stdout/stderr to the console again, but this 
> affects the "system" call in ruby, see "process.c" that stdout/stderr
> is being used. 

It just flushes them to avoid problems which occur if buffers have partial
contents in them before the child starts up - otherwise the stored data
could be output twice (once when your app eventually flushes its buffer, and
once when the child eventually flushes its buffer)

Otherwise, "system" doesn't do any writes to stdout/stderr. It's the child
process which does so: any child is quite entitled to write to stdout and/or
stderr while it's running, in fact that's the normal way in which it would
interact with the system.

Regards,

Brian.