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

> This is my RCR proposal:  Let child-processes inherit from
> rb_stdout/rb_stderr, so that stdout/stderr is untouched :-)

That makes no sense, because rb_stdout/rb_stderr are just wrappers (or
containers, or proxy-objects, call them what you will) on top of
stdout/stderr. They are the *same* Unix fds. The distinction you are making
is artificial.

This is what OO people call the "delegator pattern": when I call
STDOUT.close, for example, it forwards a close() request to the libc object
FILE *stdout, which in turn is a container on fd 1.

If you want the child process to have a different files opened on fd 1
and/or fd 2, then after the fork() you simply reopen fd1/fd2. You can do
this in Ruby as follows:

   pid = fork do
     f = File.open("/tmp/junk","w")
     STDOUT.reopen(f)
     f.close
     exec("ls /dev")
   end
   Process.waitpid(pid)
   puts "I am done now (and my stdout is untouched)"

You should find that the output of ls has been put in /tmp/junk, but the
stdout of the parent process remains as it was.

Brian.