Eryk Sun added the comment:
I forgot about the much older issue for this problem. I'm closing this issue,
because the broken behavior should be fixed, not documented.
--
resolution: -> duplicate
stage: -> resolved
status: open -> closed
superseder: -> subprocess failing in GUI appl
Eryk Sun added the comment:
This problem can be addressed most easily in _get_handles() by combining the
case of an invalid standard handle with that of a NULL standard handle, for
which a file handle is validated via GetFileType(). However, that leaves a
small window for the handle to becom
Eryk Sun added the comment:
An exception (not a crash) is possible if a standard handle is invalid and a
Popen call tries to replace one or two of the other standard handles (e.g.
stdin is invalid and you pass the argument stdout=PIPE). Note that subprocess
uses the standard handles directly,
R. David Murray added the comment:
A warning is not appropriate (we reserve those for things that are security
related, pretty much). A sentence might be, though. For example, we could
change the initial discussion of the run function to say:
This does not capture stdout or stderr by defau
New submission from Steve Barnes:
When running under pythonw, or pyinstaller with the -w flag, modules that use
subprocess calls such as popen, run, etc. will crash if the default
`stdout=None, stderr=None` behaviour is used rather than PIPE. This is an
obscure problem which is very hard to de
