[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.

Hi Jess,

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.

with thanks,

Noel Taylor


More information about the Chicago mailing list