From: "Mauricio Fernández" <batsman.geo@...>
Date: 2003-05-15T22:27:35+09:00
Subject: Re: RCR for child execution

On Thu, May 15, 2003 at 09:14:00PM +0900, Simon Strandgaard wrote:
> On Thu, 15 May 2003 18:29:50 +0900, ts wrote:
> 
> >>>>>> "S" == Simon Strandgaard <0bz63fz3m1qt3001@sneakemail.com> writes:
> > 
> > S> I think my proprosal a minor patch  and I think its possible.
> > 
> >  Well, it's easy : #system is
> > 
> >   rb_define_global_function("system", rb_f_system, -1);
> > 
> >  If you don't like it, you write your own version and then you call
> >  rb_define_global_function() to change the definition of #system
> > 
> >  Then you do the same with fork, and backquote
> 
> OK.. I have now replaced 'system' with a system which can redirect output
> elsewhere.  I use pipes + threads so that stdout/stderr can go to a
> string.  BTW: people said that this was *impossible* :-)

I think you should read the thread again (I know it's HUGE but that's
kinda your fault ;-), because this was already suggested and IRC even
implemented before.

Don't forget this DOES NOT fix the general problem in any way, i.e. it does
not satisfy all 4 requirements of [ruby-talk:71397] at the same time.
Please read that post and think on it for a while ;)

I know several people have said it already, but I will join my voice to
theirs to see if it makes a difference:

the general problem cannot be solved without changing UN*X.
HOWEVER: you can do the stuff with system, backquote and fork and it's
solving a sizeable part (in fact matz agreed this could be useful if a
good name was found, and spawn was proposed). BUT this is not what you
have been *really* asking for from the beginning (1). When given this
option you went for the impossible one (the one that IS really impossible,
the thing you're doing now was never told to be impossible, and what's
more, was even suggested to you, but you didn't like it).

There's no way you can have one part of your process (that in C) with one
stdout and another with a different one (Ruby). BUT you can make sandboxes
or ensure that all I/O goes through functions defined by you (but then
again it's really, really difficult to make them impossible to bypass)
and that way effectively reach the same end result.

(1) the problem is that the requirements expressed in your postings have
been changing all the time. Everybody kept targeting your "current
needs", offering solutions and even implementations. First you wanted A,
then somebody told you had better do B, then you said C would be great
but you were rightfully told C was impossible, so better forget about
it. Then you implement B and say "BTW people said that this was *impossible*".

Come on :-)


-- 
 _           _                             
| |__   __ _| |_ ___ _ __ ___   __ _ _ __  
| '_ \ / _` | __/ __| '_ ` _ \ / _` | '_ \ 
| |_) | (_| | |_\__ \ | | | | | (_| | | | |
|_.__/ \__,_|\__|___/_| |_| |_|\__,_|_| |_|
	Running Debian GNU/Linux Sid (unstable)
batsman dot geo at yahoo dot com

* JHM wonders what Joey did to earn "I'd just like to say, for the record,
  that Joey rules."
	-- Seen on #Debian