As the current PATH value is taken directly from the process environment it contains both the system and user's PATH values. The subsequent call to SetEnvironmentVariable() will set all these paths in the user's PATH variable, duplicating those paths already set in the system PATH.
An additional more subtle problem is that any changes to the PATH environment variable made in the process's environment (or inherited from parent processes), but which have not been persisted to the Windows registry, will inadvertently be persisted by the current approach. That is, a caller may end up adding multiple additional entries to the user's PATH instead of only the intended path.
Both issues can be handled by retrieving the user's PATH setting with GetEnvironmentVariable() (as done in location_in_new_path()) instead of using the PATH from the process environment.
On Windows the handling of updating the user's
PATH
is flawed: https://github.com/ofek/userpath/blob/30a143c4f3b9a794c0c3e99ca7b76f47e20744fe/userpath/interface.py#L36As the current
PATH
value is taken directly from the process environment it contains both the system and user'sPATH
values. The subsequent call toSetEnvironmentVariable()
will set all these paths in the user'sPATH
variable, duplicating those paths already set in the systemPATH
.An additional more subtle problem is that any changes to the
PATH
environment variable made in the process's environment (or inherited from parent processes), but which have not been persisted to the Windows registry, will inadvertently be persisted by the current approach. That is, a caller may end up adding multiple additional entries to the user'sPATH
instead of only the intended path.Both issues can be handled by retrieving the user's
PATH
setting withGetEnvironmentVariable()
(as done inlocation_in_new_path()
) instead of using thePATH
from the process environment.