S
skip
I'm converting some os.popen calls to use subprocess.Popen. I had
previously been ignoring stdout and stderr when using os.popen. The primary
motivation to switch to subprocess.Popen now is that I now want to check
stderr, so would have to make code changes to use os.popen[34] anyway.
Might as well go whole hog and switch to the new API.
The library documentation doesn't talk a lot about long-lived subprocesses
other than the possibility of deadlock when using Popen.wait(). Ideally, I
would write to the subprocess's stdin, check for output on stdout and
stderr, then lather, rinse, repeat. Is it safe to assume that if the stdout
and/or stderr pipes have nothing for me the reads on those file objects (I'm
using PIPE for all three std* files) will return immediately with an empty
string for output? They won't block, will they? Will a broken pipe IOError
get raised as for os.popen() or do I have to call Popen.poll() even in error
situations?
Thanks,
previously been ignoring stdout and stderr when using os.popen. The primary
motivation to switch to subprocess.Popen now is that I now want to check
stderr, so would have to make code changes to use os.popen[34] anyway.
Might as well go whole hog and switch to the new API.
The library documentation doesn't talk a lot about long-lived subprocesses
other than the possibility of deadlock when using Popen.wait(). Ideally, I
would write to the subprocess's stdin, check for output on stdout and
stderr, then lather, rinse, repeat. Is it safe to assume that if the stdout
and/or stderr pipes have nothing for me the reads on those file objects (I'm
using PIPE for all three std* files) will return immediately with an empty
string for output? They won't block, will they? Will a broken pipe IOError
get raised as for os.popen() or do I have to call Popen.poll() even in error
situations?
Thanks,