Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PATH environment variable changed to include MaxTo but lost nvm-windows path location #688

Closed
cwgabel opened this issue Jan 2, 2021 · 3 comments
Assignees
Labels
bug Confirmed bug in MaxTo.
Milestone

Comments

@cwgabel
Copy link

cwgabel commented Jan 2, 2021

New install on Windows 10. Only installed Chrome with this fresh install, then nvm-windows, then MaxTo.

C:\Users\cw>nvm

Running version 1.1.7.

Usage:

nvm arch : Show if node is running in 32 or 64 bit mode.
....
nvm version : Displays the current running version of nvm for Windows. Aliased as v.

C:\Users\cw>path
PATH=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0;C:\WINDOWS\System32\OpenSSH;%NVM_HOME%;%NVM_SYMLINK%;C:\Users\cw\AppData\Local\Microsoft\WindowsApps;C:\Users\cw\AppData\Roaming\nvm;C:\Program Files\nodejs

C:\Users\cw>


Now after installing MaxTo: (of course I reloaded my cmd shell)

Microsoft Windows [Version 10.0.19042.631]
(c) 2020 Microsoft Corporation. All rights reserved.

C:\Users\cw>nvm
'nvm' is not recognized as an internal or external command,
operable program or batch file.

C:\Users\cw>path
PATH=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0;C:\WINDOWS\System32\OpenSSH;%NVM_HOME%;%NVM_SYMLINK%;%USERPROFILE%\AppData\Local\Microsoft\WindowsApps;%NVM_HOME%;%NVM_SYMLINK%;

C:\Users\cw>set NVM_HOME
NVM_HOME=C:\Users\cw\AppData\Roaming\nvm

C:\Users\cw>set PATH=%PATH%;C:\Users\cw\AppData\Roaming\nvm

C:\Users\cw>path
PATH=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0;C:\WINDOWS\System32\OpenSSH;%NVM_HOME%;%NVM_SYMLINK%;%USERPROFILE%\AppData\Local\Microsoft\WindowsApps;%NVM_HOME%;%NVM_SYMLINK%;;C:\Users\cw\AppData\Roaming\nvm

C:\Users\cw>nvm

Running version 1.1.7.

Usage:

nvm arch : Show if node is running in 32 or 64 bit mode.
...
nvm version : Displays the current running version of nvm for Windows. Aliased as v.

C:\Users\cw>

Clearly it is an easy fix on my part, but thought you would be interested. NEVER had an app install impact my PATH variable.

Don't know what I could of done on my new setup to make this happen....

@github-actions
Copy link

github-actions bot commented Jan 2, 2021

Thank you for creating your first issue. We will get to it as soon as possible. This is an automated message designed to manage your expectations. We will most likely respond to your message during Norwegian business hours. If you should think of any additional information, please feel free to add it as a comment. If you are reporting a bug or incompatibility, make sure you include the versions of MaxTo, Windows and any incompatible program.

@vegardlarsen vegardlarsen added the bug Confirmed bug in MaxTo. label Jan 4, 2021
@vegardlarsen vegardlarsen self-assigned this Jan 4, 2021
@vegardlarsen
Copy link
Member

Thank you for reporting this issue. It is likely caused by the fact that Environment.GetEnvironmentVariable("PATH", EnvironmentVariableTarget.User) will replace all other environment variables in the PATH before returning it; so that we don't really know what the PATH was before we started. We try to compensate for this, by reversing the replacement of environment variables (I can't say exactly if that is the cause, but I believe it has to be).

OK then, so why doesn't MaxTo just use SET path=%path%;(new path) when it needs to update the PATH? This method is run quite often, so we don't want to append the new path repeatedly and all the time.

I will be looking into if there are ways we can do this where we don't have to do the reverse replacement of env. variables.

@vegardlarsen
Copy link
Member

Having finally had the time to investigate this a bit more thoroughly, I have found the bug in MaxTo that causes this, and the fix for it will be in version 2.2.0. It turns out we were trying to be a bit to clever and were looking up the PATH in the registry instead of through Environment.GetEnvironmentVariable, and my statement above was slightly wrong (it will sometimes replace environment variables in the returned string, but it appears only under certain conditions).

@vegardlarsen vegardlarsen added this to the 2.2.0 milestone Jan 24, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Confirmed bug in MaxTo.
Projects
None yet
Development

No branches or pull requests

2 participants