17.5. popen2
— Subprocesses with accessible I/O streams
Deprecated since version 2.6: This module is obsolete. Use the subprocess
module. Check
especially the Replacing Older Functions with the subprocess Module section.
This module allows you to spawn processes and connect to their input/output/error pipes and obtain their return codes under Unix and Windows.
The subprocess
module provides more powerful facilities for spawning new
processes and retrieving their results. Using the subprocess
module is
preferable to using the popen2
module.
The primary interface offered by this module is a trio of factory functions.
For each of these, if bufsize is specified, it specifies the buffer size for
the I/O pipes. mode, if provided, should be the string 'b'
or 't'
; on
Windows this is needed to determine whether the file objects should be opened in
binary or text mode. The default value for mode is 't'
.
On Unix, cmd may be a sequence, in which case arguments will be passed
directly to the program without shell intervention (as with os.spawnv()
).
If cmd is a string it will be passed to the shell (as with os.system()
).
The only way to retrieve the return codes for the child processes is by using
the poll()
or wait()
methods on the Popen3
and
Popen4
classes; these are only available on Unix. This information is
not available when using the popen2()
, popen3()
, and popen4()
functions, or the equivalent functions in the os
module. (Note that the
tuples returned by the os
module’s functions are in a different order
from the ones returned by the popen2
module.)
-
popen2.
popen2
(cmd[, bufsize[, mode]]) Executes cmd as a sub-process. Returns the file objects
(child_stdout, child_stdin)
.
-
popen2.
popen3
(cmd[, bufsize[, mode]]) Executes cmd as a sub-process. Returns the file objects
(child_stdout, child_stdin, child_stderr)
.
-
popen2.
popen4
(cmd[, bufsize[, mode]]) Executes cmd as a sub-process. Returns the file objects
(child_stdout_and_stderr, child_stdin)
.New in version 2.0.
On Unix, a class defining the objects returned by the factory functions is also available. These are not used for the Windows implementation, and are not available on that platform.
-
class
popen2.
Popen3
(cmd[, capturestderr[, bufsize]]) This class represents a child process. Normally,
Popen3
instances are created using thepopen2()
andpopen3()
factory functions described above.If not using one of the helper functions to create
Popen3
objects, the parameter cmd is the shell command to execute in a sub-process. The capturestderr flag, if true, specifies that the object should capture standard error output of the child process. The default is false. If the bufsize parameter is specified, it specifies the size of the I/O buffers to/from the child process.
-
class
popen2.
Popen4
(cmd[, bufsize]) Similar to
Popen3
, but always captures standard error into the same file object as standard output. These are typically created usingpopen4()
.New in version 2.0.
17.5.1. Popen3 and Popen4 Objects
Instances of the Popen3
and Popen4
classes have the following
methods:
-
Popen3.
poll
() Returns
-1
if child process hasn’t completed yet, or its status code (seewait()
) otherwise.
-
Popen3.
wait
() Waits for and returns the status code of the child process. The status code encodes both the return code of the process and information about whether it exited using the
exit()
system call or died due to a signal. Functions to help interpret the status code are defined in theos
module; see section Process Management for theW*()
family of functions.
The following attributes are also available:
-
Popen3.
fromchild
A file object that provides output from the child process. For
Popen4
instances, this will provide both the standard output and standard error streams.
-
Popen3.
tochild
A file object that provides input to the child process.
-
Popen3.
childerr
A file object that provides error output from the child process, if capturestderr was true for the constructor, otherwise
None
. This will always beNone
forPopen4
instances.
-
Popen3.
pid
The process ID of the child process.
17.5.2. Flow Control Issues
Any time you are working with any form of inter-process communication, control
flow needs to be carefully thought out. This remains the case with the file
objects provided by this module (or the os
module equivalents).
When reading output from a child process that writes a lot of data to standard
error while the parent is reading from the child’s standard output, a deadlock
can occur. A similar situation can occur with other combinations of reads and
writes. The essential factors are that more than _PC_PIPE_BUF
bytes
are being written by one process in a blocking fashion, while the other process
is reading from the first process, also in a blocking fashion.
There are several ways to deal with this situation.
The simplest application change, in many cases, will be to follow this model in the parent process:
import popen2
r, w, e = popen2.popen3('python slave.py')
e.readlines()
r.readlines()
r.close()
e.close()
w.close()
with code like this in the child:
import os
import sys
# note that each of these print statements
# writes a single long string
print >>sys.stderr, 400 * 'this is a test\n'
os.close(sys.stderr.fileno())
print >>sys.stdout, 400 * 'this is another test\n'
In particular, note that sys.stderr
must be closed after writing all data,
or readlines()
won’t return. Also note that os.close()
must be
used, as sys.stderr.close()
won’t close stderr
(otherwise assigning to
sys.stderr
will silently close it, so no further errors can be printed).
Applications which need to support a more general approach should integrate I/O
over pipes with their select()
loops, or use separate threads to read each
of the individual files provided by whichever popen*()
function or
Popen*
class was used.
See also
- Module
subprocess
- Module for spawning and managing subprocesses.