From: Brian Candler <B.Candler@...>
Date: 2003-05-13T04:04:26+09:00
Subject: Re: RCR for child execution

On Tue, May 13, 2003 at 03:04:01AM +0900, Simon Strandgaard wrote:
> Assignment to stdout/stderr is not legal.. of couse reopen should be used.

But then you cannot get back the original thing which stdout/stderr was
connected to (e.g. if it were a pipe, or an unnamed file)

It might be possible to dup() them to a spare descriptor, dup2() the new fd
onto fd1/2, and then dup2() the copy back again. I've not tried that.

> Thanks for your fine example.. But it won't work!!
> I am sharing a bunch of classes between C++ and Ruby, within the same
> thread. Your code is 2 differnt processes!
> I don't want to marshall all my classes via a pipe between C++ and Ruby.

So don't.

I'm sorry, but you really do seem to have missed the point of embedding:
that your C/Ruby amalgamation is a single program.

The other important point is: Unix provides a default execution environment
where your program gets these character streams "stdin", "stdout", "stderr",
but you are under no obligation to use them. People write GUI programs in C
all the time, just by calling GTk or Qt or whatever, and ignore the
existence of stdin/stdout/stderr altogether. If you want to embed Ruby into
something like that, then you write your Ruby to behave in a similar way.

Would you really expect to embed a C library like 'ncurses' or 'gettext'
into a graphical C program and expect it to work? Of course not. Where would
it get its keystrokes from? Nowhere, unless you fork off a child and map
your GUI's keystrokes and display to the child's stdin and stdout.

Hence it makes little sense to embed a Ruby program written to use
stdin/stdout directly into a C program, unless you spawn a process to
communicate with it.

You might want to consider 'stdin' for a bit. Suppose the Ruby code you
embed into your program says:
            ...
            puts "Press any key to continue"
            gets

What would you have it do then?

Brian.