[issue11139] subprocess: Arguments to .bat scripts get interpreted by shell

[Arve Knudsen]

Arve Knudsen <arve.knudsen at gmail.com> added the comment:

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 at bugs.python.org>wrote:

>
> R. David Murray <rdmurray at 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 at bugs.python.org>
> <http://bugs.python.org/issue11139>
> _______________________________________
>

----------
Added file: http://bugs.python.org/file20714/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11139>
_______________________________________
-------------- next part --------------
I wasn&#39;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&#39;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.<div>
<br></div><div>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?</div>
<div><br></div><div>Arve<br><br><div class="gmail_quote">On Mon, Feb 7, 2011 at 6:06 PM, R. David Murray <span dir="ltr">&lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
R. David Murray &lt;<a href="mailto:rdmurray at bitdance.com">rdmurray at bitdance.com</a>&gt; added the comment:<br>
<br>
</div>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).<br>

<br>
----------<br>
<div><div></div><div class="h5"><br>
_______________________________________<br>
Python tracker &lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;<br>
&lt;<a href="http://bugs.python.org/issue11139" target="_blank">http://bugs.python.org/issue11139</a>&gt;<br>
_______________________________________<br>
</div></div></blockquote></div><br></div>