[issue22442] subprocess.check_call hangs on large PIPEd data.

juj added the comment: This issue still reads open, but there has not been activity in a long time. May I ask what is the latest status on this? Also, any chance whether this will be part of Python 2.x? -- ___ Python tracker

[issue22442] subprocess.check_call hangs on large PIPEd data.

Akira Li added the comment: Victor, the message in my patch is copied almost verbatim from the current subprocess' documentation [1] [1] https://hg.python.org/cpython/file/850a62354402/Doc/library/subprocess.rst#l57 People use `call(cmd, stdout=PIPE)` as a *broken* way to suppress output i.e

[issue22442] subprocess.check_call hangs on large PIPEd data.

STINNER Victor added the comment: The first place to warn uses about dangerous function calls is the documentation, and your patch doesn't touch the documentation. You can for example suggest to use check_output(), getstatusouptut() or getoutput(). --

[issue22442] subprocess.check_call hangs on large PIPEd data.

Akira Li added the comment: @juj: DeprecationWarning is generated if PIPE is passed to call() as any positional or keyword argument in particular stdin, stdout, stderr. It also applies to check_call() that uses call() internally. -- ___ Python tracker

[issue22442] subprocess.check_call hangs on large PIPEd data.

juj added the comment: Hmm, that path does it for stdout=PIPE in subprocess.call only? It could equally apply to stderr=PIPE in subprocess.call as well, and also to both stdout=PIPE and stderr=PIPE in subprocess.check_call? -- ___ Python tracker

[issue22442] subprocess.check_call hangs on large PIPEd data.

Akira Li added the comment: > What do you think? I would prefer to deprecate PIPE argument for subprocess.call(): issue DeprecationWarning in 3.5 and raise ValueError in 3.6+ I've uploaded a patch that issues the warning. -- keywords: +patch type: -> enhancement versions: +Python 3.5

[issue22442] subprocess.check_call hangs on large PIPEd data.

juj added the comment: Very good question akira. In one codebase where I have fixed this kind of bug, see https://github.com/kripken/emscripten/commit/1b2badd84bc6f54a3125a494fa38a51f9dbb5877 https://github.com/kripken/emscripten/commit/2f048a4e452f5bacdb8fa31481c55487fd64d92a the intended usa

[issue22442] subprocess.check_call hangs on large PIPEd data.

Akira Li added the comment: > This is a documented failure on the python subprocess page, > but why not just fix it up directly in python itself? If you want to discard the output; you could use: check_call(args, stdin=DEVNULL, stdout=DEVNULL, stderr=STDOUT) check_call() passes its parameter

[issue22442] subprocess.check_call hangs on large PIPEd data.

juj added the comment: The same observation applies to subprocess.call() as well. -- ___ Python tracker ___ ___ Python-bugs-list maili

[issue22442] subprocess.check_call hangs on large PIPEd data.

Changes by STINNER Victor : -- components: +Windows nosy: +haypo ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue22442] subprocess.check_call hangs on large PIPEd data.

New submission from juj: On Windows, write a.py: import subprocess def ccall(cmdline, stdout, stderr): proc = subprocess.Popen(['python', 'b.py'], stdout=subprocess.PIPE, stderr=subprocess.PIPE) proc.communicate() if proc.returncode != 0: raise subprocess.CalledProcessError(proc.returnc