bug: Pathman rewrites user env path value type as REG_SZ
Describe the bug
Running sample cmd:
%userprofile%\bin\pathman.exe add ~/bin
Expected: %userprofile%\bin (or perhaps expanded, e g C:\Users\JohnDoe\bin ) added to REG_EXPAND_SZ Path value of HKCU\Environment key.
Actual: Path entry is added as expected (well, almost), but value is rewritten as REG_SZ type.
To Reproduce
- In fresh win11, check registry. Example:
Notice type of PATH value.
- In cmd.exe, run sample cmd (
%userprofile%\bin\pathman.exe add ~/bin). Check registry again.
I get:
or
C:\Users\mawid6>reg query "HKCU\Environment"
HKEY_CURRENT_USER\Environment
Path REG_SZ C:\Users\mawid6/bin;C:\Users\mawid6\AppData\Local\Programs\Python\Python313\Scripts\;C:\Users\mawid6\AppData\Local\Programs\Python\Python313\;C:\Users\mawid6\AppData\Local\Programs\Python\Launcher\;%USERPROFILE%\AppData\Local\Microsoft\WindowsApps;C:\Users\mawid6\AppData\Local\Programs\Microsoft VS Code\bin;C:\Users\mawid6\AppData\Local\Microsoft\WinGet\Links;C:\Users\mawid6\AppData\Roaming\npm;%USERPROFILE%\go\bin
TEMP REG_EXPAND_SZ %USERPROFILE%\AppData\Local\Temp
Device / Machine (please complete):
- OS/Device: Win 11, Microsoft Windows [Version 10.0.26100.3775]
- Arch: x64 (installed amd64 version, e g
https://git.rootprojects.org/root/pathman/releases/download/v0.5.2/pathman-v0.5.2-windows-amd64.zip). - Version 0.5.2.
Additional context / Impact
~~I doubt this has any actual impact on anything, TBH, but it just looks rather "clueless" and I immediately reacted with a feeling of unease, like "if this passes, how can I trust this command?". And I think it should be easy to fix, have not checked the code.~~
git-bash startup broke for me, since my user env path has a few %USERPROFILE%\bin like entries. When I manually changed the valuetype back to REG_EXPAND_SZ, it worked fine again - so it seems that was the culprit. It seems likely that it parses the regedit values based, and based on the type - if it is REG_EXPAND_SZ - it does variable expansion.
This was written in Go to be cross-platform (including cygwin), back before PowerShell had support for PATH editing of strings longer than 256 characters.
The solution would be to rewrite this in PowerShell now that the default PowerShell install on Windows 10 and Windows 11 seems to support all of the features that are necessary to do this correctly.
So, I checked the code the culprit is most likely simply:
https://github.com/therootcompany/pathman/blob/81b2207b817b666e6cebe98fbed03d9b8cdb6a25/winpath/winpath_windows.go#L77
Where it is using SetStringValue, but should be using SetExpandStringValue:
func (k Key) SetStringValue(name, value string) error
func (k Key) SetExpandStringValue(name, value string) error
https://pkg.go.dev/golang.org/x/sys/windows/registry
Don't you think?
I opened a silly PR for it. Not a go developer, so whatever CI tests you have would have to do the testing. https://github.com/therootcompany/pathman/pull/14
Oh, drat! This is my work account. Sorry.
Oh, and the impact is greater than I thought. I just noticed a problem with git bash, and I assume that its startup is using some reg parser that does not expand if the type is not REG_EXPAND_SZ since I now have a few %USERPROFILE% path entries in my env path in bash...