This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author r.david.murray
Recipients brian.curtin, eric.araujo, eric.smith, narnie, r.david.murray, skrah
Date 2010-07-19.13:27:03
SpamBayes Score 0.0017920674
Marked as misclassified No
Message-id <1279546026.4.0.695865436054.issue9265@psf.upfronthosting.co.za>
In-reply-to
Content
Stefan: patch looks good to me in principle, but it looks like you made it against 2.7, and we commit to py3k first now.  The test does not work correctly on py3k because of a bytes/string issue, but I'm not clear on why the problem happens (I haven't looked in to it, I just observe that the test fails).  And yes I think this should go into 2.6 and 3.1 as well.

Narnie: if only we had enough manpower to handle all bugs as rapidly.  Please keep learning and help us where you can :)

As for your test...I'm not clear if you are saying Stefan's patch fixes or problem or not, but please observe this:

>>> os.execv('/bin/bash', ['/bin/sh', 'echos', 'foo'])
/bin/sh: echos: No such file or directory

That is, it is /bin/bash that is running, but it thinks its name is '/bin/sh' because that is what we passed in arg0 in the execv call.
Similarly you could do:

>>> os.execv('/bin/bash', ['my_funny_walk', 'echos', 'foo'])
my_funny_walk: echos: No such file or directory

So, popen is *calling* the correct shell, it's just that it is giving it the wrong arg[0] name, which Stefan's patch fixes.
History
Date User Action Args
2010-07-19 13:27:06r.david.murraysetrecipients: + r.david.murray, eric.smith, eric.araujo, brian.curtin, skrah, narnie
2010-07-19 13:27:06r.david.murraysetmessageid: <1279546026.4.0.695865436054.issue9265@psf.upfronthosting.co.za>
2010-07-19 13:27:04r.david.murraylinkissue9265 messages
2010-07-19 13:27:03r.david.murraycreate