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 eryksun
Recipients docs@python, eryksun, gaborjbernat, keller00, paul.moore, steve.dower, tim.golden, vinay.sajip, zach.ware
Date 2020-10-18.20:06:19
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
> Also, why would we document the Windows rules, but not the POSIX 
> rules? They are arguably just as strange to someone who doesn't 
> know them.

POSIX rules are simply to search PATH for the filename as passed, and if it has a slash in it, the path is resolved against the working directory. There is no implicit search of the application directory, current directory, and system directories. There is no search for "dir/file" in *every* search path directory instead of just resolving against the working directory. There is no figuring out when ".exe" or PATHEXT extensions will be appended or how to search for a filename that has no extension by appending a trailing "." to the name. And there is no massive inconsistency between the search semantics of shell=True and shell=False. What happens with "platform semantics" in Windows is complicated compared to POSIX. I'm more comfortable telling people to search via shutil.which() than relying on the platform search. I'd be much more comfortable if that's what subprocess.Popen() just did on its own. But we're locked into platform semantics, and I don't see that changing.
Date User Action Args
2020-10-18 20:06:19eryksunsetrecipients: + eryksun, paul.moore, vinay.sajip, tim.golden, docs@python, zach.ware, steve.dower, gaborjbernat, keller00
2020-10-18 20:06:19eryksunsetmessageid: <>
2020-10-18 20:06:19eryksunlinkissue42041 messages
2020-10-18 20:06:19eryksuncreate