You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
subprocess makes environment blocks with duplicate keys on Windows #91018
or either of the documented equivalents ({**os.environ, ...} or (os.environ | {...})), and passes the resulting environment to subprocess.run or subprocess.Popen, the spawned process may get an environment containing both HTTP_PROXY and http_proxy. Most Win32 software will see only the first one, which contains the unmodified value from os.environ.
Because os.environ forces all keys to upper case, it's possible to work around this by using only upper case keys in the update, but that behavior of os.environ is nonstandard (bpo-46861), and subprocess shouldn't depend on it always being true, nor should end users have to.
Since dicts preserve order, the user's (presumable) intent is preserved in the env argument. I think subprocess should do something like
This should be handled in _winapi.CreateProcess(). An environment block is technically required to be sorted. (Ages ago this was a MUST requirement for getting and setting variables to work correctly, since the implementation depended on the sort order, but I think nowadays it's a SHOULD requirement.) For example, see the documentation of CreateProcessW() [1]:
If an application provides an environment block, ... explicitly create
these environment variable strings, sort them alphabetically (because
the system uses a sorted environment)
"Changing Environment Variables" is more specific [2]:
All strings in the environment block must be sorted alphabetically by name.
The sort is case-insensitive, Unicode order, without regard to locale.
CompareStringOrdinal() [3] implements a case-insensitive ordinal comparison. When a key compares as equal, either keep the current one in the sorted list, or replace it with the new key.
Activity
benrg commentedon Feb 26, 2022
On Windows, if one writes
or either of the documented equivalents ({**os.environ, ...} or (os.environ | {...})), and passes the resulting environment to subprocess.run or subprocess.Popen, the spawned process may get an environment containing both
HTTP_PROXYandhttp_proxy. Most Win32 software will see only the first one, which contains the unmodified value from os.environ.Because os.environ forces all keys to upper case, it's possible to work around this by using only upper case keys in the update, but that behavior of os.environ is nonstandard (bpo-46861), and subprocess shouldn't depend on it always being true, nor should end users have to.
Since dicts preserve order, the user's (presumable) intent is preserved in the env argument. I think subprocess should do something like
to discard duplicate keys, keeping only the rightmost one.
eryksun commentedon Feb 26, 2022
This should be handled in _winapi.CreateProcess(). An environment block is technically required to be sorted. (Ages ago this was a MUST requirement for getting and setting variables to work correctly, since the implementation depended on the sort order, but I think nowadays it's a SHOULD requirement.) For example, see the documentation of CreateProcessW() [1]:
"Changing Environment Variables" is more specific [2]:
CompareStringOrdinal() [3] implements a case-insensitive ordinal comparison. When a key compares as equal, either keep the current one in the sorted list, or replace it with the new key.
---
[1] https://docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-createprocessw
[2] https://docs.microsoft.com/en-us/windows/win32/procthread/changing-environment-variables
[3] https://docs.microsoft.com/en-us/windows/win32/api/stringapiset/nf-stringapiset-comparestringordinal
eryksun commentedon Feb 26, 2022
I suggest closing this issue as a duplicate of bpo-43702.
zooba commentedon Aug 25, 2022
Duplicate of #87868