As stated in PEP 11, 3.4 removes code on Windows platforms where
COMSPEC points to command.com. The w9xpopen project in Visual Studio
was added to support that case, and there was a special case in subprocess
to cover that situation. This change removes the w9xpopen project from
the Visual Studio solution and removes any references to the w9xpopen
executable.
child subprocess.PIPE parent file descriptors on child error prior to
exec().
This would lead to race conditions in multithreaded programs where
another thread opened a file reusing the fd which was then closed out
from beneath it by the errant second close.
child subprocess.PIPE parent file descriptors on child error prior to
exec().
This would lead to race conditions in multithreaded programs where
another thread opened a file reusing the fd which was then closed out
from beneath it by the errant second close.
child subprocess.PIPE parent file descriptors on child error prior to
exec().
This would lead to race conditions in multithreaded programs where
another thread opened a file reusing the fd which was then closed out
from beneath it by the errant second close.
all together and just include the repr of the data in the exception
itself instead of the useless string "Unknown".
This code path is unlikely to even be possible to take given the
nature of the pipe it gets subprocess data from.
all together and just include the repr of the data in the exception
itself instead of the useless string "Unknown".
This code path is unlikely to even be possible to take given the
nature of the pipe it gets subprocess data from.
all together and just include the repr of the data in the exception
itself instead of the useless string "Unknown".
This code path is unlikely to even be possible to take given the
nature of the pipe it gets subprocess data from.
misleading error message stating that args[0] did not exist when
either the cwd or executable keyword arguments specified a path that
did not exist.
It now keeps track of if the child got as far as preexec and reports it if
not back to the parent via a special "noexec" error message value in
the error pipe so that the cwd can be blamed for a failed chdir
instead of the exec of the executable being blamed instead.
The executable is also always reported accurately when exec fails.
Unittests enhanced to cover these cases.
On error, call(), check_call(), check_output() and getstatusoutput() functions
of the subprocess module now kill the process, read its status (to avoid
zombis) and close pipes.
module: the piped streams can now be properly read from or written to.
(this was broken due to the 2.x to 3.x transition; communicate() support
is still sketchy)
Remove the pure Python POSIX subprocess implementation.
If non-CPython VMs (are there any for 3.x yet?) were somehow depending
on this, they already have the exact same set of problems with Python
code being executed after os.fork() that _posixsubprocess was written
to deal with. They should implement an equivalent outside of Python.
Brian Curtin
Andrew Svetlov
Gregory P. Smith
Victor Stinner
Vinay Sajip
Antoine Pitrou
Victor Stinner
Charles-François Natali
Ross Lagerwall