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
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue11139>
> _______________________________________
>