I wasn't saying that subprocess is interpreting the arguments, but that the shell is. Which was highly unexpected to me when outside of shell mode (i.e., shell == False). From some further testing, though, I see that the transformation from sequence to command line on Windows plays a bigger role than I was aware of even though I've used subprocess since it was introduced in the standard library. That is, I see that also in Python 2.6, arguments to .bat scripts get interpreted if command arguments are passed to subprocess as a string rather in a list.

My current conclusion is that there has been a hole in the subprocess design the whole time, so that my case (start a Windows shell script like an executable) has just worked by chance, due to that I have passed arguments as a list which then got implicitly protected (even outside of shell mode). Maybe subprocess.Popen should take another option to implement the old behaviour of protecting arguments supplied as a list, given that this should be a common enough case?

Arve

On Mon, Feb 7, 2011 at 6:06 PM, R. David Murray <report@bugs.python.org> wrote:

R. David Murray <rdmurray@bitdance.com> added the comment:

The point is that subprocess (now!) is *not* interpreting the arguments when shell is false.  It is passing them through to Windows.  What windows does with them after that is out of the control of subprocess (and always has been).

----------

_______________________________________
Python tracker <report@bugs.python.org>
<http://bugs.python.org/issue11139>
_______________________________________