> 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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
