Arve Knudsen <arve.knud...@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 <rep...@bugs.python.org>wrote:
>
> R. David Murray <rdmur...@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 <rep...@bugs.python.org>
> <http://bugs.python.org/issue11139>
> _______________________________________
>
----------
Added file: http://bugs.python.org/file20714/unnamed
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue11139>
_______________________________________
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.<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"><<a
href="mailto:rep...@bugs.python.org";>rep...@bugs.python.org</a>></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 <<a
href="mailto:rdmur...@bitdance.com";>rdmur...@bitdance.com</a>> 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 <<a
href="mailto:rep...@bugs.python.org";>rep...@bugs.python.org</a>><br>
<<a href="http://bugs.python.org/issue11139";
target="_blank">http://bugs.python.org/issue11139</a>><br>
_______________________________________<br>
</div></div></blockquote></div><br></div>
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
