[Chicago] capturing output from subprocesses
Noel Thomas Taylor
nttaylor at uchicago.edu
Wed Nov 16 22:06:41 CET 2005
> The os.openpty() call seems to be working fine on your installation.
> Maybe it was added after the 2.2 that I have on my Solaris box? I just
> checked and it's there in 2.4 (ActiveState) on Solaris. So now it
> seems to work OK on your IRIX box (Python 2.3.5) and the Solaris and
> Linux boxes I have tested, both with Python 2.4.
I've tested it too and it works fine all around. This is the greatest.
I'll be giving you big props in the final code.
I had a few closing questions. At the beginning of the parent fork, you
close the file descriptor for writing to stdErr, since you won't need it;
meanwhile in the child fork you close the file descriptor for reading from
stdErr, since you won't need it either. This all makes sense, but can't
you also close the corresponding file descriptors for writing to and
reading from stdOut, just as you did for stdErr? I added these "closes" to
the code and noticed no ill effects, but thought I'd ask in case there was
some reason I wasn't seeing.
Were you using your own function 'mygetpty()' on platforms / versions of
Python where os.getpty() is not supported, like the Python 2.2 you had on
your Solaris machine? I'm not sure about just when Python introduced this
function, or if it is supported under Solaris. I don't have a Solaris
machine here to test, and Python's own documentation pages are not very
specific about which platforms support this function.
Finally, I pretty much understand what's happening, but why do you have to
make the calls to dup2? I've seen this in several process-spawning codes
but have never figured out just why it's necessary.
More information about the Chicago