Fixes a possible hang when using a timeout on subprocess.run() while capturing output. If the child process spawned its own children or otherwise connected its stdout or stderr handles with another process, we could hang after the timeout was reached and our child was killed when attempting to read final output from the pipes. (cherry picked from commit 580d2782f70f8e0bed7ec20abb03d740cb83b5da) Co-authored-by: Gregory P. Smith <greg@krypto.org>
(cherry picked from commit 182e1d1f849757439f2031504f142fa4e1251611) Co-authored-by: Matthias <xmatthias@outlook.com>
As noted by @eryksun in [1] and [2], using _cleanup and _active(in __del__) is not necessary on Windows, since: > Unlike Unix, a process in Windows doesn't have to be waited on by > its parent to avoid a zombie. Keeping the handle open will actually > create a zombie until the next _cleanup() call, which may be never > if Popen() isn't called again. This patch simply defines `subprocess._active` as `None`, for which we already have the proper logic in place in `subprocess.Popen.__del__`, that prevents it from trying to append the process to the `_active`. This patch also defines `subprocess._cleanup` as a noop for Windows. [1] https://bugs.python.org/issue37380GH-msg346333 [2] https://bugs.python.org/issue36067GH-msg336262 Signed-off-by: Ruslan Kuprieiev <ruslan@iterative.ai> (cherry picked from commit 042821ae3cf537e01963c9ec85d1a454d921e826) Co-authored-by: Ruslan Kuprieiev <kupruser@gmail.com>
Fix an unintended ValueError from :func:`subprocess.run` when checking for conflicting `input` and `stdin` or `capture_output` and `stdout` or `stderr` args when they were explicitly provided but with `None` values within a passed in `**kwargs` dict rather than as passed directly by name. (cherry picked from commit 8cc605acdda5aff250ab4c9b524a7560f90ca9f3) Co-authored-by: Rémi Lapeyre <remi.lapeyre@henki.fr>
The "-I" command line option (run Python in isolated mode) is now also copied by the multiprocessing and distutils modules when spawning child processes. Previously, only -E and -s options (enabled by -I) were copied. subprocess._args_from_interpreter_flags() now copies the -I flag. (cherry picked from commit 9de363271519e0616f4a7b59427057c4810d3acc) Co-authored-by: Victor Stinner <vstinner@redhat.com>
subprocess.Popen now copies the startupinfo argument to leave it unchanged: it will modify the copy, so that the same STARTUPINFO object can be used multiple times. Add subprocess.STARTUPINFO._copy() private method. Python 3.7 backport from master makes the copy() private: renamed to _copy(). (cherry picked from commit 483422f57e5d8c8bf8820fec29fc9b96bb15d4ef)
* Revert "bpo-31961: subprocess now accepts path-like args (GH-4329)" This reverts commit dd42cb71f2cb02f3a32f016137b12a146bc0d0e2. (cherry picked from commit be50a7b627d0aa37e08fa8e2d5568891f19903ce) Co-authored-by: Serhiy Storchaka <storchaka@gmail.com>
Allow os.PathLike args in subprocess APIs.
Add "capture_output=True" option to subprocess.run, this is equivalent to setting stdout=PIPE, stderr=PIPE but is much more readable.
Do not allow receiving a SIGINT to cause the subprocess module to trigger an immediate SIGKILL of the child process. SIGINT is normally sent to all child processes by the OS at the same time already as was the established normal behavior in 2.7 and 3.2. This behavior change was introduced during the fix to https://bugs.python.org/issue12494 and is generally surprising to command line tool users who expect other tools launched in child processes to get their own SIGINT and do their own cleanup. In Python 3.3-3.6 subprocess.call and subprocess.run would immediately SIGKILL the child process upon receiving a SIGINT (which raises a KeyboardInterrupt). We now give the child a small amount of time to exit gracefully before resorting to a SIGKILL. This is also the case for subprocess.Popen.__exit__ which would previously block indefinitely waiting for the child to die. This was hidden from many users by virtue of subprocess.call and subprocess.run sending the signal immediately. Behavior change: subprocess.Popen.__exit__ will not block indefinitely when the exiting exception is a KeyboardInterrupt. This is done for user friendliness as people expect their ^C to actually happen. This could cause occasional orphaned Popen objects when not using `call` or `run` with a child process that hasn't exited. Refactoring involved: The Popen.wait method deals with the KeyboardInterrupt second chance, existing platform specific internals have been renamed to _wait(). Also fixes comment typos.