benrg <benrud...@gmail.com> added the comment:
It turns out that, on Windows 7 32-bit with COMSPEC pointing to command.com,
platform.popen('dir').read() works with w9xpopen and fails (no output) without
it.
But the reason has nothing to do with the old Win9x problem. It's because
subprocess always quotes the command line after /c, which command.com doesn't
understand. But w9xpopen decodes the command line (in the runtime, before
main() is called) and then reencodes it, this time quoting only arguments with
spaces in them. Command.com then gets /c dir, and is happy. It would be
interesting if this was the bug that led to w9xpopen being used in NT for the
last ten years.
There are layers upon layers of brokenness here. w9xpopen should not be messing
with the command line in the first place; it should call GetCommandLine() and
pass the result untouched to CreateProcess (after skipping its own name). It
certainly should not be using the argv[] contents, which are parsed with an
algorithm that doesn't match the one used by cmd.exe. The decoding-encoding
process munges the command line in hard-to-understand ways. Additionally,
subprocess.py doesn't quote the shell name (my usual shell is C:\Program
Files\TCCLE12\TCC.EXE), and it converts an argument list to a string using
list2cmdline even when shell=True, which makes little sense to me.
I think w9xpopen should be deleted and forgotten. It was written badly and has
apparently been largely ignored for 10+ years. There is probably a better
solution to the problem even on Win9x, such as a worker thread in the Python
process that waits on both the process and pipe handles. But also, all of the
shell=True code in subprocess.py needs to be rethought from the ground up. I
don't think it should exist at all; far better to provide convenient support in
subprocess for setting up pipelines, and require people to explicitly invoke
the shell for the few remaining legitimate use cases. That should probably be
discussed elsewhere, though.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue2405>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
