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

os.popen2 and os.popen3 in python 2.6 incompatible with os.popen* in python 2.5 #49579

Closed
jahakala mannequin opened this issue Feb 20, 2009 · 11 comments
Closed

os.popen2 and os.popen3 in python 2.6 incompatible with os.popen* in python 2.5 #49579

jahakala mannequin opened this issue Feb 20, 2009 · 11 comments
Assignees
Labels
stdlib Python modules in the Lib dir type-bug An unexpected behavior, bug, or error

Comments

@jahakala
Copy link
Mannequin

jahakala mannequin commented Feb 20, 2009

BPO 5329
Nosy @amauryfa, @pitrou, @pjenvey
Files
  • os-popen.diff: Lib/os.py fix against release26-maint
  • os-popen-list.patch: Unit tests for os.popen2, os.popen3, and os.popen4 with a list instead of a string
  • subprocess-conversion-doc.patch: update the docs for converting from os.popen* to subprocess.Popen
  • subprocess-conversion-doc2.patch
  • 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 = 'https://github.com/pjenvey'
    closed_at = <Date 2009-09-29.19:19:57.532>
    created_at = <Date 2009-02-20.09:14:02.672>
    labels = ['type-bug', 'library']
    title = 'os.popen2 and os.popen3 in python 2.6 incompatible with os.popen* in python 2.5'
    updated_at = <Date 2009-09-29.19:19:57.531>
    user = 'https://bugs.python.org/jahakala'

    bugs.python.org fields:

    activity = <Date 2009-09-29.19:19:57.531>
    actor = 'pjenvey'
    assignee = 'pjenvey'
    closed = True
    closed_date = <Date 2009-09-29.19:19:57.532>
    closer = 'pjenvey'
    components = ['Library (Lib)']
    creation = <Date 2009-02-20.09:14:02.672>
    creator = 'jahakala'
    dependencies = []
    files = ['13141', '14791', '14839', '14996']
    hgrepos = []
    issue_num = 5329
    keywords = ['patch']
    message_count = 11.0
    messages = ['82523', '82567', '90259', '90266', '92008', '92227', '92228', '92229', '92279', '93304', '93318']
    nosy_count = 6.0
    nosy_names = ['exarkun', 'amaury.forgeotdarc', 'pitrou', 'pjenvey', 'jahakala', 'maxb']
    pr_nums = []
    priority = 'high'
    resolution = 'fixed'
    stage = None
    status = 'closed'
    superseder = None
    type = 'behavior'
    url = 'https://bugs.python.org/issue5329'
    versions = ['Python 2.6', 'Python 2.7']

    @jahakala
    Copy link
    Mannequin Author

    jahakala mannequin commented Feb 20, 2009

    The implementation in python 2.6 expects the cmd argument to be a string.
    The documentation - help(os.popen3) - states that the cmd argument can
    be a sequence on Unix.

    This difference may cause programs that work with python 2.5 to fail
    with python 2.6

    I have tested the patch attached with one of my scripts that failed with
    python 2.6 and the fix appears to work.

    @jahakala jahakala mannequin added stdlib Python modules in the Lib dir type-bug An unexpected behavior, bug, or error labels Feb 20, 2009
    @pitrou
    Copy link
    Member

    pitrou commented Feb 21, 2009

    Adding a couple of unit tests would be nice.

    @maxb
    Copy link
    Mannequin

    maxb mannequin commented Jul 8, 2009

    With or without tests, this is a regression from Python 2.5 - shouldn't
    something be done about that?

    @amauryfa
    Copy link
    Member

    amauryfa commented Jul 8, 2009

    The test is the proof the the regression, and shows the change in
    behavior and the purpose of the development.
    There happens to be a test for os.popen3 (in Lib/test/test_popen2.py)
    which passes a list; this one at least passes.

    os.popen3() accepts a sequence, except that since 2.6, the first item is
    the whole command string, and additional items are treated as additional
    shell arguments!

    Your patch is correct. A unit test could be:
    w, r, e = os.popen3(['echo', 'hello'])
    assert r.read() == 'hello\n'
    And should be disabled on non-posix platforms.

    @exarkun
    Copy link
    Mannequin

    exarkun mannequin commented Aug 27, 2009

    Attached os-popen-list.patch which includes all of the earlier
    os-popen.diff and adds tests which fail without this patch and pass with
    it. They also pass on Python 2.5. The patch is against the Python 2.6
    maintenance branch, but presumably it should be applied to trunk as well.

    @pjenvey
    Copy link
    Member

    pjenvey commented Sep 4, 2009

    The subprocess docs (in Doc/library/subprocess.rst and the module itself)
    need to also reflect this change

    @exarkun
    Copy link
    Mannequin

    exarkun mannequin commented Sep 4, 2009

    Hey Philip,

    I'm not sure I follow. The patch only changes the os module, not the
    subprocess module. What subprocess documentation do you think needs to
    be updated?

    @pjenvey
    Copy link
    Member

    pjenvey commented Sep 4, 2009

    Sorry, I meant the docs describing how to convert os.popen* calls to
    subprocess calls. They assume the shell arg is always True regardless of
    the cmd arg type. Those docs are probably the original source of this bug

    @exarkun
    Copy link
    Mannequin

    exarkun mannequin commented Sep 5, 2009

    Ah, thanks for the clarification, Philip. I've attached another patch
    updating those docs.

    @pjenvey
    Copy link
    Member

    pjenvey commented Sep 29, 2009

    Here's the doc change with a lil more clarification, and I've also applied
    it to the module's own docs

    @pjenvey
    Copy link
    Member

    pjenvey commented Sep 29, 2009

    applied in r75143/r75144, in time for 2.6.3. thanks!

    @pjenvey pjenvey closed this as completed Sep 29, 2009
    @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

    3 participants