Eryk Sun added the comment:
The Unix implementation of subprocess.Popen follows the behavior of os.execvpe,
which is an outlier. Other execvpe implementations, such as the one added to
glibc in 2009, search PATH in the current environment instead of the passed
environment. As such, and given the natural expectations of a Windows
programmer, I do not see the current behavior of the Windows implementation as
incorrect. It's a documentation bug.
On a related note, the Popen documentation for Windows should also mention that
defining the environment variable NoDefaultCurrentDirectoryInExePath removes
the current directory from the executable search path, in both CreateProcess
and cmd.exe (i.e. w/ shell=True). This feature was introduced in Windows Vista,
so it applies to Python 3.5+.
> Python actually executes the program, but argv[0] is inconsistent with
> cwd. Imagine that the called program wants to resolve its own path:
> It joins cwd and argv[0] and gets
> "C:\Users\Jenda\Bug
> reports\Python\subprocess\subdir\subdir\print_argv+cwd.exe"
A Windows program would call GetModuleFileName with hModule as NULL, which
returns the path of the process executable. There's also the pseudo-environment
variable __APPDIR__.
Using argv[0] from the command line would be unreliable. For example:
>>> _ = run('"spam & eggs" /c echo %__APPDIR__%',
... executable=os.environ['ComSpec'])
C:\Windows\system32\
>>> _ = run('"spam & eggs" -m calendar 2017 2',
... executable=sys.executable)
February 2017
Mo Tu We Th Fr Sa Su
1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28
----------
nosy: +eryksun
_______________________________________
Python tracker <[email protected]>
<http://bugs.python.org/issue15533>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
