subproc.py v 1.7 has several fixes and clarifications of 1.6, which
had been released for a while now.  We've been using it in some work
projects, working out bugs and refining features in the process.
Along the way i've been getting the sense that while it does some
things well, subproc.py tries to do too much, and is a bit
overcomplicated (and perhaps fragile) thereby.

You may find it suitable to your purposes - extras, including the new
RecordFile, provide some handy tools - but you may also want to look
at popen2.py in the python distribution for interacting with
subprocesses.  Popen2 avoids some of complications and questionable
areas where subproc goes.

Ken Manheimer, 04/1998
[email protected]

Here's the announcement of v 1.5:

Subject: subproc.py v 1.5
From: [email protected] (Ken Manheimer)
To: [email protected]
Date: Mon, 23 Jan 1995 19:00:11 -0500 (EST)
Organization: National Institute of Standards and Technology

The diffs are larger than the file, so i'm posting the entire thing.

It's......  a new version of subproc.py.

It rectifies a big problem with the prior version, and tidies up the
approach to non-blocking reads.  However, i have found one application
where it mysteriously misbehaves, when the old version didn't, so you
may want to test before switching to this version.

The new version of the Subprocess class now cleans up the pipe file
descriptors on deletion, so the process' file table is not exhausted
as subprocesses are generated and discarded.

I've implemented a 'readbuf', based on the 'iobuf' donn cave
implemented in his version of the subproc code, which disposes of the
dual-thrust approach to non-blocking reads.  I had originally
believed, incorrectly, that chunking the reads (eg, 'os.read(1024)')
dictates hanging until the number of chars are read, which is not the
case.  Ability to chunk regular reads cancels the advantages of the
new io-buffer-size regulation mechanism, so i'm dropping it in favor
of a single, simple approach.  The code is simpler, without,
presumably, sacrificing functionality.

Due simply to lack of time, i have not implemented a signal hander to
track expiration of the child (and automatically do the cleanup).  It
would certainly be proper to do implement such a thing, but i've been
furtively stealing time to do this partial cleanup.

cheers,

Ken, 1995