From: Simon Strandgaard <0bz63fz3m1qt3001@...>
Date: 2003-05-13T08:47:44+09:00
Subject: Re: RCR for child execution

On Tue, 13 May 2003 08:39:34 +0900, Brian Candler wrote:

> On Tue, May 13, 2003 at 05:45:45AM +0900, Simon Strandgaard wrote:
>> BOOM = system+backquote outputs to stdout/stderr,  interfering with the
>> output of the C/C++ application.
>> 
>> This interference is what to avoid. I want to be able to
>> redirect Rubys output elsewhere: logfile/statusbox/text-buffer.
> 
> But the process you run with system/backquote is not Ruby, and therefore its
> output is not Ruby's output. It's a completely different program, run using
> fork + exec, but run in the same Unix environment as your main program (as
> it should be: fork simply duplicates the existing process)

This is exactly the my situation im in. 


> You can redirect Ruby's output elsewhere ($defout), but it's the child's
> output that you are asking about.

True


> Now, you can always replace 'system' with a function with runs a child,
> captures its output, and forwards it to a Ruby IO object. 

True... But this is only a patch-work, not a "nice" solution.
Still rb_warn and friends outputs to stderr. 
I am searching for the nice solution :-)


> Matz suggested
> putting something like 'system2' in the the Ruby library for this purpose.

A 'system2' call is not future-safe.. maybe some day one wants to control
the sheduling priority of the process to be spawned.
I think a 'System' class could be more future-safe. 

sys = System.new("command" => "xmms", "prio" => "realtime", "out" => myhandler)
sleep 20
sys.kill(9)   # killing children ruthless!!

I just read Ara Howards suggestion for a 'spawn'.. This is even better :-)

Neither 'system2' nor a System class would require any changes to the Core
of ruby. It could easily be implemented as a Ruby/C extension.
My problem is slight different and would require changes to Rubys Core.

 
[snip the remaining thread]

A short break... Getting something to eat.. 
The remaining part looks good, I like the diagrams  and  we starting to
understand eachother :-)

--
Simon Strandgaard