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 dabrahams, docs@python, mark, r.david.murray
Date 2010-04-29.15:49:43
SpamBayes Score 0.000267107
Marked as misclassified No
Message-id <>
Changing the default value of shell is not an option anyway.

The behavior you describe is exactly what one should expect: the environment in which the executable is located is the environment of the process calling Popen, not the environment passed to Popen.  The environment passed to Popen is the environment in which the subprocess executes.  When using shell=True, this is the environment in which the shell executes, and the *shell* then looks up the executable in that new environment.  As far as I know this behavior is the same on both Windows and Unix, and thus is not a portability issue.  (How the shell works can be a portability issue, though.)

I'm not sure that this needs to be documented explicitly, as it is a logical consequence of how subprocesses work, but if you want to suggest a doc update I'll take a look at it.

I suspect your Unix example is about the fragility of the rules for computing sys.executable (there's an issue in the tracker about may get a different result on trunk), but I haven't checked it.
Date User Action Args
2010-04-29 15:49:46r.david.murraysetrecipients: + r.david.murray, mark, docs@python, dabrahams
2010-04-29 15:49:46r.david.murraysetmessageid: <>
2010-04-29 15:49:44r.david.murraylinkissue8557 messages
2010-04-29 15:49:44r.david.murraycreate