path environment variable not created correctly

[Rom265]

BPO	40542
Nosy	@pfmoore, @tjguk, @zware, @eryksun, @zooba, @Rom265

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2020-05-07.13:01:00.594>
created_at = <Date 2020-05-06.23:19:40.465>
labels = ['3.8', 'invalid', 'type-bug', 'expert-installation', 'OS-windows']
title = 'path environment variable not created correctly'
updated_at = <Date 2020-05-07.14:49:19.728>
user = 'https://github.com/Rom265'

bugs.python.org fields:

activity = <Date 2020-05-07.14:49:19.728>
actor = 'zach.ware'
assignee = 'none'
closed = True
closed_date = <Date 2020-05-07.13:01:00.594>
closer = 'steve.dower'
components = ['Installation', 'Windows']
creation = <Date 2020-05-06.23:19:40.465>
creator = 'Roman'
dependencies = []
files = []
hgrepos = []
issue_num = 40542
keywords = []
message_count = 4.0
messages = ['368312', '368321', '368335', '368347']
nosy_count = 6.0
nosy_names = ['paul.moore', 'tim.golden', 'zach.ware', 'eryksun', 'steve.dower', 'Roman']
pr_nums = []
priority = 'normal'
resolution = 'not a bug'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue40542'
versions = ['Python 3.8']

[Rom265]

The Python 3.8 for Windows installer has an option to add the install folder to the path environment variable. It adds the path to the front of the list so that it is the first item. According to my understanding, this is bad behavior. It should add new path items to the end of the list because Windows searches in order. c:\windows\system32 should remain the first item in the list. This is a classic mistake of installers.

[eryksun]

Prepending directories ahead of system directories in PATH affects programs that implement their own search, which includes shells such as cmd.exe that do so in order to support PATHEXT efficiently. That said, note that temporarily prepending to PATH in a particular environment is common. Consider an activated virtual environment or a developer command prompt.

Usually programs defer to a Windows API function when searching for a file. The API uses search paths from the runtime library functions RtlGetSearchPath, RtlGetExePath, and LdrGetDllPath.

With WINAPI SearchPathW, the default search path is from RtlGetSearchPath (undocumented). It includes the following directories in non-safe search mode (the default mode):

1. %APPDIR%
2. %CD%
3. %SystemRoot%\System32
4. %SystemRoot%\System
5. %SystemRoot%
6. %PATH%

and the following adjusted order in safe search mode:

1. %APPDIR%
2. %SystemRoot%\System32
3. %SystemRoot%\System
4. %SystemRoot%
5. %CD%
6. %PATH%

Safe search mode can be set via WINAPI SetSearchPathMode(BASE_SEARCH_PATH_ENABLE_SAFE_SEARCHMODE).

With WINAPI CreateProcessW, the search path is from RtlGetExePath (undocumented). This is similar to the result from RtlGetSearchPath, except, instead of supporting a safe search mode, RtlGetExePath allows excluding the current directory (%CD%) from the search path by setting the environment variable NoDefaultCurrentDirectoryInExePath.

With WINAPI LoadLibrary[Ex]W, the system uses the search path from LdrGetDllPath (undocumented). The default DLL search path at startup under normal circumstances is the same as the safe-mode result from RtlGetSearchPath -- except for special casing of known system DLLs and API sets.

[zooba]

Yes, it is bad behaviour, but it is very upsetting for many people to not have the option. This is why it's disabled by default, and why I regularly discourage people from selecting the option (and quite often get abused for taking the trouble... oh well... that's apparently how open-source life works these days).

If you install just for the current user, it will only appear ahead of the user's own PATH entries, which are stored separately from the system ones and concatenated automatically (unless the whole thing exceeds a certain length, in which case you just lose PATH entries... another reason to avoid it).

Adding to the end of the PATH would leave people broken and confused as any other install of Python would still take precedence. So to minimize breakage, it goes to the front, but the per-user install is the default.

So thanks for the support, but unfortunately we don't have any viable way to move forward on it. Tell people not to add to PATH and to run py.exe instead - which we've been doing for years, but it doesn't really have much effect.