Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

subprocess: Arguments to .bat scripts get interpreted by shell #55348

Closed
ArveKnudsen mannequin opened this issue Feb 7, 2011 · 10 comments
Closed

subprocess: Arguments to .bat scripts get interpreted by shell #55348

ArveKnudsen mannequin opened this issue Feb 7, 2011 · 10 comments
Labels
stdlib Python modules in the Lib dir type-bug An unexpected behavior, bug, or error

Comments

@ArveKnudsen
Copy link
Mannequin

ArveKnudsen mannequin commented Feb 7, 2011

BPO 11139
Nosy @bitdancer
Superseder
  • bpo-8972: subprocess.list2cmdline doesn't quote the & character
  • Files
  • case.zip: Case demonstrating bug
  • unnamed
  • unnamed
  • Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.

    Show more details

    GitHub fields:

    assignee = None
    closed_at = <Date 2011-02-07.15:33:36.034>
    created_at = <Date 2011-02-07.14:49:36.222>
    labels = ['invalid', 'type-bug', 'library']
    title = 'subprocess: Arguments to .bat scripts get interpreted by shell'
    updated_at = <Date 2011-02-07.19:02:11.105>
    user = 'https://bugs.python.org/ArveKnudsen'

    bugs.python.org fields:

    activity = <Date 2011-02-07.19:02:11.105>
    actor = 'Arve.Knudsen'
    assignee = 'none'
    closed = True
    closed_date = <Date 2011-02-07.15:33:36.034>
    closer = 'SilentGhost'
    components = ['Library (Lib)']
    creation = <Date 2011-02-07.14:49:36.222>
    creator = 'Arve.Knudsen'
    dependencies = []
    files = ['20711', '20715', '20716']
    hgrepos = []
    issue_num = 11139
    keywords = []
    message_count = 10.0
    messages = ['128119', '128125', '128129', '128135', '128139', '128144', '128145', '128147', '128150', '128151']
    nosy_count = 3.0
    nosy_names = ['r.david.murray', 'SilentGhost', 'Arve.Knudsen']
    pr_nums = []
    priority = 'normal'
    resolution = 'not a bug'
    stage = 'resolved'
    status = 'closed'
    superseder = '8972'
    type = 'behavior'
    url = 'https://bugs.python.org/issue11139'
    versions = ['Python 3.1', 'Python 2.7', 'Python 3.2', 'Python 3.3']

    @ArveKnudsen
    Copy link
    Mannequin Author

    ArveKnudsen mannequin commented Feb 7, 2011

    As a regression from Python 2.6, when running .bat scripts on Windows with f.ex. subprocess.call under Python 2.7.1, arguments get interpreted by the shell. This bit me in the way that I could no longer pass arguments containing the character '|' to .bat scripts, something that works fine under Python 2.6.

    To see the bug in action, run tst.py in the attached case.zip with Python 2.7.1. The case also demonstrates that the '|' character only gets interpreted when launching cmd scripts, not e.g. python.exe.

    @ArveKnudsen ArveKnudsen mannequin added stdlib Python modules in the Lib dir type-bug An unexpected behavior, bug, or error labels Feb 7, 2011
    @SilentGhost
    Copy link
    Mannequin

    SilentGhost mannequin commented Feb 7, 2011

    This seem to have been discussed in bpo-8972: closing as a duplicate.

    @SilentGhost SilentGhost mannequin closed this as completed Feb 7, 2011
    @bitdancer
    Copy link
    Member

    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 bpo-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.

    @ArveKnudsen
    Copy link
    Mannequin Author

    ArveKnudsen mannequin commented Feb 7, 2011

    Would you mind defining why the 2.7 behaviour is correct in this particular
    case? The list2cmdline behaviour discussed in bpo-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 bpo-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\>


    @bitdancer
    Copy link
    Member

    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).

    @ArveKnudsen
    Copy link
    Mannequin Author

    ArveKnudsen mannequin commented Feb 7, 2011

    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\>


    @bitdancer
    Copy link
    Member

    As noted in bpo-8972, it's not clear what such a mode should actually do. If you have a concrete proposal you could make it, probably on the python-ideas mailing list. But I'm personally not in favor of it; I prefer maintaining as much API consistency between windows and linux as we reasonably can.

    @ArveKnudsen
    Copy link
    Mannequin Author

    ArveKnudsen mannequin commented Feb 7, 2011

    The non-obvious thing with 8972 is what to do with an argument list when the
    'shell' option is True, isn't it? I can't see how it overlaps with my case.
    My suggestion is a flag to enable argument protection in Popen, either just
    for arguments passed as a list (i.e., like how it's done in 2.6) or maybe
    also for the case where you pass the command as a string (I haven't
    considered that case yet, since it's not directly interesting to me).

    I can actually see that exarkun suggests something along the same lines in
    8972: 'implement the cmd.exe quoting rules in a different function from the
    MS C runtime rules'.

    Arve

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

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

    As noted in bpo-8972, it's not clear what such a mode should actually do.
    If you have a concrete proposal you could make it, probably on the
    python-ideas mailing list. But I'm personally not in favor of it; I prefer
    maintaining as much API consistency between windows and linux as we
    reasonably can.

    ----------


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


    @bitdancer
    Copy link
    Member

    Yes, having a cmd.exe 'quote' function, parallel to the shutil 'quote' function, would be an excellent addition to the stdlib. You could open a feature request for that.

    @ArveKnudsen
    Copy link
    Mannequin Author

    ArveKnudsen mannequin commented Feb 7, 2011

    I'll keep it in mind.

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

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

    Yes, having a cmd.exe 'quote' function, parallel to the shutil 'quote'
    function, would be an excellent addition to the stdlib. You could open a
    feature request for that.

    ----------


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


    @ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
    Labels
    stdlib Python modules in the Lib dir type-bug An unexpected behavior, bug, or error
    Projects
    None yet
    Development

    No branches or pull requests

    1 participant