Message128144
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>
> _______________________________________
> |
File name |
Uploaded |
unnamed
|
Arve.Knudsen,
2011-02-07.18:12:17
|
|
Date |
User |
Action |
Args |
2011-02-07 18:12:18 | Arve.Knudsen | set | recipients:
+ Arve.Knudsen, r.david.murray, SilentGhost |
2011-02-07 18:12:17 | Arve.Knudsen | link | issue11139 messages |
2011-02-07 18:12:17 | Arve.Knudsen | create | |
|