Would you mind defining why the 2.7 behaviour is correct in this particular case? The list2cmdline behaviour discussed in issue 8972 has to do with shell commandlines; in this case, in my eyes any shell invocation (in order to run a .bat I guess) is only an implementation detail. Is the 2.7 behaviour correct since the Win32 function CreateProcess happens to start a shell to run .bat files, which in turn interprets the arguments? I'm guessing this is what happens...
There certainly can't be any universal definition in subprocess saying that arguments to shell scripts shall be interpreted by the shell; when trying now *on Linux* to launch a corresponding .sh script through subprocess, arguments are passed through verbatim. I should like to see subprocess maintain (or keep maintaining, rather) a uniform interface, so that arguments are not interpreted so long as the 'shell' argument equals False.
I understand completely that list2cmdline should implement C library behaviour, and not protect arguments from the shell, but that doesn't mean it should automatically define the behaviour of other functions such as Popen and call.
Arve
On Mon, Feb 7, 2011 at 4:38 PM, R. David Murray
<report@bugs.python.org> wrote:
R. David Murray <rdmurray@bitdance.com> added the comment:
Well, it's not really a duplicate, but rather invalid, since the 2.7 behavior is more correct than the 2.6 behavior. Not that it matters all that much what particular resolution is attached to a bug.
Arve: It is unfortunate that the bug fix in issue 8972 caused a regression for you, but at this point what is done is done.
Also, for future reference, when attaching files to an issue please attach text files only. They are much easier to review.
----------
nosy: +r.david.murray
resolution: duplicate -> invalid
stage: -> committed/rejected
superseder: -> subprocess.list2cmdline doesn't quote the & character