[Python-Dev] Strange behavior of subprocess.Popen._get_handles under Windows

[Mark Hammond]

> Now I finally found that my problem are these two lines in
> subprocess.py:
> 
>                 if stdin is None and stdout is None and stderr is None:
>                     return (None, None, None, None, None, None)
> 
> These lines add an interesting quirk: if I explicitly specify any
> single channel (i.e. stdout=1) the problem suddenly disappears, and if
> I just comment these lines altogether my problem vanishes completely!
> (i.e. output redirection works absolutely well)
> 
> Further investigations showed that it seems to be some strange OS
> quirk/bug,

I'm not quite with you here - what strange OS bug do you think you have
found?  I expect that such a bug would be well documented somewhere, even if
not directly by MS.

> To my thinking, this will not change behavior when any std* arguments
> are passed to Popen, and the only case when it kicks in is when no
> std* arguments are specified and the resulting side effects are
> previously failing cases start working correctly. Or am I wrong here,
> are there any side effects of using STARTF_USESTDHANDLES that I'm
> missing here?

MSDN documents that without that flag, hStdInput will be "the keyboard
buffer" while the output handles will default to "the console window's
buffer" - which sounds significantly different to your expectation that the
existing handles will be used as the default (unless I misunderstand).
Sadly, your mail isn't clear enough for me to be sure about what semantics
you are seeing and exactly what you expect, and I don't have time to
experiment.  Maybe a clear indication of the OS bug you are referring to,
and some complete examples which demonstrate the problems you are having
would help.

Cheers,

Mark