> 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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4