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 eric.smith, eryksun, paul.moore, steve.dower, tim.golden, uranusjr, zach.ware
Date 2019-11-25.11:00:39
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
> whens searching for executables, Windows gives "exes that are in the
> same directory as the currently executing code" priority over PATH.

That subprocess lets CreateProcessW use a platform-dependent search that prioritizes the application directory has come up in previous issues. To avoid this, we'd have to implement our own search for the given or parsed executable name. Then pass the fully-qualified executable path as the lpApplicationName name of CreateProcessW. This is how CMD works, since it has its own search routine that incorporates the PATHEXT environment variable.

Because the application directory is searched before the working directory (if the working directory is searched at all, depending on context), this issue also affects searching for executable paths that contain a path separator. In Unix a relative path that contains a path separator is always relative to the working directory, but Windows CreateProcessW uses a normal search for a relative name unless it explicitly references the working directory as "." (e.g. ".\Scripts\pip.exe" instead of "Scripts\pip.exe").
Date User Action Args
2019-11-25 11:00:40eryksunsetrecipients: + eryksun, paul.moore, eric.smith, tim.golden, zach.ware, steve.dower, uranusjr
2019-11-25 11:00:39eryksunsetmessageid: <>
2019-11-25 11:00:39eryksunlinkissue38905 messages
2019-11-25 11:00:39eryksuncreate