Eryk Sun added the comment:
Virtual commands that are parsed to start with "python" are restricted to the
list of installed versions of Python -- unless the virtual command allows
searching and the Python command has no version specification (e.g.`#!
/usr/bin/env python`). "python3" is versioned, so the launcher will not search
for it using the default SearchPath path.
For reference, see maybe_handle_shebang() [1], lines 1265-69:
command += 6; /* skip past "python" */
if (search && ((*command == L'\0') || isspace(*command))) {
/* Command is eligible for path search, and there
* is no version specification.
*/
The default SearchPath path includes the py.exe application directory, the
process working directory, system directories, and the %Path% directories. This
default search path can be made 'safe' via SetSearchPathMode or a registry
setting, but doing so just swaps the order to search system directories before
the working directory. It doesn't remove the working directory, unlike the safe
search used by CreateProcess when %NoDefaultCurrentDirectoryInExePath% is
defined.
I think the implementation of find_on_path() could be improved. It should
always try appending .EXE, .COM, .BAT, and .CMD if the bare command isn't
found, not just if the command doesn't contain a ".". It's not unheard of to
have a name with mulitple dots in it, e.g. "spam4.2.exe". Also, looping over
all of the extensions listed in %PathExt% is of doubtful value. We don't call
ShellExecuteEx to execute arbitrary file types, such as .VBS, .VBE, .JS, .JSE,
.WSF, .WSH, and .MSC.
[1]: https://hg.python.org/cpython/file/v3.6.0b3/PC/launcher.c#l1112
----------
nosy: +eryksun
versions: +Python 3.6, Python 3.7
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28686>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
