Naming tips for popen4-style library?

[Jonathan Paisley]

Hello,

I've been developing a library for communicating with sub processes via
pipes, which is modelled somewhat after Python's Popen4 class [1]
(although the semantics are slightly different).

I'm looking for some suggestions for a better name for the class (and
any other comments, too).

I initially wrote this because I wanted to be able to do popen() type
things without the shell getting in the way. You can pass arguments to
sub processes without need for quoting etc.

Main features:

* Object-oriented interface
- procedural interface could easily be built on top, but haven't
decided on best way yet
* Access to stdin, stdout and stderr independently
* Optional redirection of each of the above, to file/socket or
/dev/null
* Can get exit status of child process (including signals)
* Send signals to child process
* Thread safe

For example:

Popen4.new('echo','$PATH') do |p|
puts p.stdout.readline #=> $PATH (and not the
expansion of that env var!)
puts p.wait.exitstatus #=> 0
end

Any comments?

Thanks.

[1] http://www.python.org/doc/2.4/lib/module-popen2.html

[Berger, Daniel]

> -----Original Message-----
> From: Jonathan Paisley [mailto:jp-...@dcs.gla.ac.uk]
> Sent: Tuesday, March 15, 2005 9:32 AM
> To: ruby-talk ML
> Subject: Naming tips for popen4-style library?
>
>
> Hello,
>
> I've been developing a library for communicating with sub
> processes via
> pipes, which is modelled somewhat after Python's Popen4 class [1]
> (although the semantics are slightly different).

Ara Howard had brought up an Open4 back in http://rubyurl.com/Pq1hj. I
mention this because the win32-open3 package already has an Open4 module
that uses Ara's API approach (i.e. returns a pid as a 4th argument).

If folks want to change things, that's fine. But the Ruby community
should try to come to a consensus as to what the API should look like
and how it should behave.

Regards,

Dan

[Jonathan Paisley]

On 15 Mar 2005, at 16:47, Berger, Daniel wrote:

> Ara Howard had brought up an Open4 back in http://rubyurl.com/Pq1hj. I
> mention this because the win32-open3 package already has an Open4
> module
> that uses Ara's API approach (i.e. returns a pid as a 4th argument).

Yes, I should have mentioned Ara's Open4. I had been talking to Ara
about the possibility of merging our two approaches (possibly providing
the procedural interface on top of the object-oriented one).

> If folks want to change things, that's fine. But the Ruby community
> should try to come to a consensus as to what the API should look like
> and how it should behave.

Good point.

In my implementation, I've avoided the double-fork technique because I
want the child to keep its association with the parent, in particular
to support sending signals and waiting on the child to complete.

Since the library manages a list of children it is able to reap them at
opportune moments.

So, I'd argue for providing both the procedural and object-oriented
approach, with the former built upon the latter. Of course, the API
would have to cover the functionality present on unix and win32.

I'm not so keen on the Open4 name - I'd prefer something like
ChildProcess.

In summary - can we come up with a consensus as to what the API should
look like and what its behaviour should be? (w.r.t. double forks,
waiting, etc).

Thanks.
Jonathan