Make win_add2path.py take effect without having to log off

[neEverett]

BPO	30374
Nosy	@pfmoore, @tjguk, @zware, @eryksun, @zooba, @neEverett
PRs	bpo-30374: Fixed several bugs in win_add2path.py #1594 bpo-30374: Fixed several bugs in win_add2path.py #1645

^{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 = None
created_at = <Date 2017-05-15.17:48:25.131>
labels = ['3.10', 'type-bug', '3.8', '3.9', 'OS-windows']
title = 'Make win_add2path.py take effect without having to log off'
updated_at = <Date 2021-03-20.07:24:27.994>
user = 'https://github.com/neEverett'

bugs.python.org fields:

activity = <Date 2021-03-20.07:24:27.994>
actor = 'eryksun'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Demos and Tools', 'Windows']
creation = <Date 2017-05-15.17:48:25.131>
creator = 'neeverett'
dependencies = []
files = []
hgrepos = []
issue_num = 30374
keywords = []
message_count = 5.0
messages = ['293727', '293733', '293738', '293739', '293754']
nosy_count = 6.0
nosy_names = ['paul.moore', 'tim.golden', 'zach.ware', 'eryksun', 'steve.dower', 'neeverett']
pr_nums = ['1594', '1645']
priority = 'normal'
resolution = None
stage = None
status = 'open'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue30374'
versions = ['Python 3.8', 'Python 3.9', 'Python 3.10']

[neEverett]

I was trying to add Python to Windows PATH and found this tool. But after I ran it and restarted the Command Prompt, nothing seemed to be changed: Command Prompt still didn't recognize Python codes. Finally I got it done by manually setting the environment variables in Windows System Properties.

Then I tried to figure out what was wrong with this script and found that it does not take effect until a reboot or log off. It's not mentioned in the content or output of the script, making it puzzling.

The cause of this inconvenience is that though the script changes the env vars, applications don't refer to the new values automatically. It is explained in a Microsoft KB article(http://support.microsoft.com/kb/104011) -- "However, note that modifications to the environment variables do not result in immediate change. For example, if you start another Command Prompt after making the changes, the environment variables will reflect the previous (not the current) values. The changes do not take effect until you log off and then log back on."

The article also provided a method to refresh the environment variables immediately -- "To effect these changes without having to log off, broadcast a WM_SETTINGCHANGE message to all windows in the system, so that any interested applications (such as Windows Explorer, Program Manager, Task Manager, Control Panel, and so forth) can perform an update."

I am going to create a PR which implements it by using ctypes.windll.user32.SendMessageTimeoutW() to broadcast the WM_SETTINGCHANGE message.

[eryksun]

Are people actually using this script? Maybe it should simply be removed. I see a few problems with it 1:

* A default value of "%PATH%" is wrong. That causes the system
 PATH to be concatenated with itself.

* For the user scripts directory, replacing appdata with
 "%APPDATA%" causes os.path.isdir to always fail.

* REG_EXPAND_SZ should only be used when '%' occurs 2 or more
 times. Otherwise use REG_SZ. An existing REG_SZ type should 
 be preserved, if the value doesn't have two or more '%' 
 characters, because the user may be reusing PATH in a 
 REG_EXPAND_SZ variable.

 (The environment gets created in 2 passes -- actually 4 
 passes if we consider that system values are loaded 
 before user values. REG_SZ values get loaded first, and 
 then REG_EXPAND_SZ values are loaded and expanded. The 
 latter may depend on REG_SZ values, and also system 
 values in the user case, but should never depend on 
 other REG_EXPAND_SZ values since the enumeration order 
 of the registry key is undefined. In practice a key is
 enumerated in definition order, not the alphabetic 
 order displayed in regedit.)

* It doesn't broadcast a WM_SETTINGCHANGE message, so it
 needlessly forces the user to log off and back on in order to
 use the modified PATH.

[neEverett]

I didn't noticed that there are other problems with this script. So maybe it needs a complete rewrite instead.
But I doubt if it should be simply deleted. Actually I think there is a litte problem with the installer: "add Python to PATH" is not selected by default when installing. I don't know if there's a reason for this. But beginners like me tend to install Python under the default configs therefore it is possible that they later find Python is not in the system PATH. Under this condition it is at least more convenient than manually setting the env vars.

[pfmoore]

The reasons for not adding Python to PATH by default are complex. We've tried both ways and neither is 100% satisfactory.

The default install is a per-user install. If we added Python to PATH, then as a user setting it would come *after* the system part of PATH. If that includes python (for example, an older version of Python), then you think you have added Python to PATH but you still get the old version. We can't add the user python to the system PATH, as it may not be accessible to other users.

We don't make an all-users Python the default because users would then not be able to "pip install" modules without using an elevated prompt. So an all-users install should be left as a choice for a system admin who understands the implications.

Long story short, it's complicated and there's no really perfect solution.

The easiest answer is to say that you should be using the "py" launcher to start Python anyway. That *is* available in PATH and will pick up your default configured Python. With that, you don't need to add anything to PATH.

[neEverett]

I think the original author adds the relative path "%APPDATA%..." with the intention to keep it effective even when the set path of APPDATA changes. However that compulsively changes the type of PATH var to REG_EXPAND_SZ.

It is reasonable that the type of PATH var should not be changed. So I think when the type is REG_SZ, not adding the %APPDATA% path and instead adding the absolute path of it should be a good idea.

I just modified my PR and fixed it this way, along with other problems that Eryk Sun mentioned.