[Issue]: nvm-update.exe: NVM for Windows should be run from a terminal such as CMD or PowerShell

[Saibamen]

What happened?

I wanted to do this via CMD and PowerShell and also after revert setting Windows Terminal as default umm terminal.

What did you expect to happen?

I will be able to run nvm-update.exe

Version

1.1.11 or newer (Default)

Which version of Windows?

Windows 10 (Default)

Which locale?

Western European

Which shell are you running NVM4W in?

Command Prompt, PowerShell

User Permissions?

Administrative Privileges, Elevated

Is Developer Mode enabled?

No (Default)

Relevant log/console output

No response

Debug Output

Running NVM for Windows with administrator privileges.

Administrator: Command Prompt - nvm  debug
Windows Version: 10.0 (Build 19045)

NVM4W Version:      1.1.12
NVM4W Path:         C:\Users\adam\AppData\Roaming\nvm\nvm.exe
NVM4W Settings:     C:\Users\adam\AppData\Roaming\nvm\settings.txt
NVM_HOME:           C:\Users\adam\AppData\Roaming\nvm
NVM_SYMLINK:        C:\Program Files\nodejs
Node Installations: C:\Users\adam\AppData\Roaming\nvm

Total Node.js Versions: 4
Active Node.js Version: v20.9.0

IPv6 is enabled. This can slow downloads significantly.

No problems detected.

Find help at https://github.com/coreybutler/nvm-windows/wiki/Common-Issues

Anything else?

After running it via CMD with admin, I have this same MessageBox, bug after closing it, I have this message in CMD window:

NVM for Windows installation not found in C:\Users\adam\AppData\Roaming\nvm

But I have installed NVM...

[Saibamen]

And now, after nvm version I have latest 1.1.12...

Strange. Looks like some IF conditions should be fixed in this updater.

[AlexDoanBB]

same issue here on my test machine, I was trying to use nvm over jenkins

I downgrade nvm to 1.1.11, this issue was gone

[eglove]

I just noticed this issue today as well.

[alexblatov]

same for me today, could find any related in changelog...

[aboe026]

Same issue for me. Seems related to this change 3c736ab and the new isTerminal function. I'm not a Go dev so not able to easily debug it, seems like it is not properly detecting a terminal though

[buckyster]

Same error message for me in Git Bash on Windows 10, using nvm-windows 1.1.12.

After I downgraded to nvm-windows 1.1.11, then it worked fine.

[aaron777collins]

Does anyone know a way around this in nvm-windows 1.1.12? I'd like to use an automated script to update/install nvm-windows and then run commands for installing, etc. via a bash script, run in git bash. Thanks!

[coreybutler]

@aaron777collins the update process is really simple. You just need to overwrite the nvm.exe file in NVM_HOME. You don't need to use the updater at all. It's just a convenience program anyway.

That said, shells using unix paths aren't supported. Git bash uses unix paths like /c/path/to/whatever which Windows can't understand. Operating in git bash is akin to running NVM4W on Linux... which isn't going to work. Still, you should be able to move files around for an update. You just can't run most nvm <command> operations in a unix-like environment.

[t-l-k]

FYI @coreybutler I seem to get this issue even when attempting to run nvm from nvm-noinstall.zip? On Windows Server 2022 (unattended install, packer hangs as a UI dialog is popped).

Easily reproduced in Windows Sandbox (Windows 11) from the Windows Powershell ISE using attached PS1 script as crafted from the manual installation advice.

Replacing the download link from latest to v1.1.11 and it works like a charm.

Warning

Only run this example in Windows Sandbox! It WILL rewrite your global system Path!

# Step 1: Remove existing Node.js installation
Get-Package -provider Programs -IncludeWindowsInstaller -Name "Node.js" | Uninstall-Package

# Step 2: Download latest portable nvm-noinstall.zip
Invoke-WebRequest -Uri "https://github.com/coreybutler/nvm-windows/releases/latest/download/nvm-noinstall.zip" -OutFile "$env:TEMP\nvm-noinstall.zip"

# Step 3: Move nvm-noinstall.zip to c:\nvm and extract files
New-Item -ItemType Directory -Force -Path "c:\nvm"
Expand-Archive -Path "$env:TEMP\nvm-noinstall.zip" -DestinationPath "c:\nvm" -Force

# Step 4: Create NVM_HOME environment variable
[System.Environment]::SetEnvironmentVariable("NVM_HOME", "c:\nvm", "Machine")

# Step 5: Create NVM_SYMLINK environment variable
[System.Environment]::SetEnvironmentVariable("NVM_SYMLINK", "c:\Program Files\nodejs", "Machine")

# Step 6: Ensure "c:\Program Files\nodejs" folder does not exist
Remove-Item -Path "c:\Program Files\nodejs" -Recurse -Force -ErrorAction Ignore
New-Item -Path "c:\Program Files\nodejs" -Type Directory -Force

# Step 7: Append NVM_HOME and NVM_SYMLINK to system PATH environment variable
$env:NVM_HOME = "c:\nvm"
$env:NVM_SYMLINK = "c:\Program Files\nodejs"
$nvmVars = @($env:NVM_HOME, $env:NVM_SYMLINK)

# Step 7.1 Reorganize active path, used as basis for updating system path
$env:Path = [System.Environment]::GetEnvironmentVariable("Path", "Machine")
$pathItems = $env:Path -split ";"
$pathItems = $pathItems | Where-Object { $_ -notin $nvmVars }
$pathItems += $nvmVars
$env:Path = $pathItems -join ";"

# Step 7.2 Set all future machine path
# NOTE: Rewriting Path will clobber REG_EXPAND_SZ to REG_SZ https://github.com/dotnet/runtime/issues/1442
[System.Environment]::SetEnvironmentVariable("Path", "$env:Path", "Machine")

Push-Location $env:NVM_HOME

$settings = @"
root: $env:NVM_HOME
path: $env:NVM_SYMLINK
arch: 64
proxy: none

"@

# NOTE: Go runtime doesn't like CRLF files
$settings = $settings -replace "`r`n", "`n"
$encoding = [System.Text.UTF8Encoding]::new($false)
[System.IO.File]::WriteAllBytes("$pwd\settings.txt", $encoding.GetBytes($settings))

# Step 8: Install major versions 14, 16, 18
nvm install 14
nvm install 16
nvm install 18

# Step 9: Set default Node 18
nvm use 18

v1.1.12 Fails

v1.1.11 Works

[t-l-k]

To be fair though, from just a plain Windows Powershell prompt in Windows Sandbox, the same script works 🤔 Must be something funky with the packer provisioner steps invocation of a Powershell session / something funky with the Windows Powershell ISE.

Here is the style of azure-arm builder packer step I used:

{
  "type": "powershell",
  "max_retries": 2,
  "inline": [
    "& c:\\tmp\\agent-image\\nvm.ps1"
  ],
  "elevated_user": "{{user `install_user`}}",
  "elevated_password": "{{user `install_password`}}"
}

[t-l-k]

Further investigation, applying any kind of stdout redirect to nvm appears to trigger the dialog warning. From a cmd terminal:

nvm use 18 >nvm.log

So in any scenario where stdout is being redirected, either by this simple cmd example, or by Start-Process arguments, or as part of some form of non-interactive automation, I assume this would fail.

[aaron777collins]

FYI @coreybutler I seem to get this issue even when attempting to run nvm from nvm-noinstall.zip? On Windows Server 2022 (unattended install, packer hangs as a UI dialog is popped).

Easily reproduced in Windows Sandbox (Windows 11) from the Windows Powershell ISE using attached PS1 script as crafted from the manual installation advice.

Replacing the download link from latest to v1.1.11 and it works like a charm.

Warning

Only run this example in Windows Sandbox! It WILL rewrite your global system Path!

# Step 1: Remove existing Node.js installation
Get-Package -provider Programs -IncludeWindowsInstaller -Name "Node.js" | Uninstall-Package

# Step 2: Download latest portable nvm-noinstall.zip
Invoke-WebRequest -Uri "https://github.com/coreybutler/nvm-windows/releases/latest/download/nvm-noinstall.zip" -OutFile "$env:TEMP\nvm-noinstall.zip"

# Step 3: Move nvm-noinstall.zip to c:\nvm and extract files
New-Item -ItemType Directory -Force -Path "c:\nvm"
Expand-Archive -Path "$env:TEMP\nvm-noinstall.zip" -DestinationPath "c:\nvm" -Force

# Step 4: Create NVM_HOME environment variable
[System.Environment]::SetEnvironmentVariable("NVM_HOME", "c:\nvm", "Machine")

# Step 5: Create NVM_SYMLINK environment variable
[System.Environment]::SetEnvironmentVariable("NVM_SYMLINK", "c:\Program Files\nodejs", "Machine")

# Step 6: Ensure "c:\Program Files\nodejs" folder does not exist
Remove-Item -Path "c:\Program Files\nodejs" -Recurse -Force -ErrorAction Ignore
New-Item -Path "c:\Program Files\nodejs" -Type Directory -Force

# Step 7: Append NVM_HOME and NVM_SYMLINK to system PATH environment variable
$env:NVM_HOME = "c:\nvm"
$env:NVM_SYMLINK = "c:\Program Files\nodejs"
$nvmVars = @($env:NVM_HOME, $env:NVM_SYMLINK)

# Step 7.1 Reorganize active path, used as basis for updating system path
$env:Path = [System.Environment]::GetEnvironmentVariable("Path", "Machine")
$pathItems = $env:Path -split ";"
$pathItems = $pathItems | Where-Object { $_ -notin $nvmVars }
$pathItems += $nvmVars
$env:Path = $pathItems -join ";"

# Step 7.2 Set all future machine path
# NOTE: Rewriting Path will clobber REG_EXPAND_SZ to REG_SZ https://github.com/dotnet/runtime/issues/1442
[System.Environment]::SetEnvironmentVariable("Path", "$env:Path", "Machine")

Push-Location $env:NVM_HOME

$settings = @"
root: $env:NVM_HOME
path: $env:NVM_SYMLINK
arch: 64
proxy: none

"@

# NOTE: Go runtime doesn't like CRLF files
$settings = $settings -replace "`r`n", "`n"
$encoding = [System.Text.UTF8Encoding]::new($false)
[System.IO.File]::WriteAllBytes("$pwd\settings.txt", $encoding.GetBytes($settings))

# Step 8: Install major versions 14, 16, 18
nvm install 14
nvm install 16
nvm install 18

# Step 9: Set default Node 18
nvm use 18

v1.1.12 Fails

v1.1.11 Works

I can confirmI'm having the same issue with the same nvm-noinstall.zip on Windows 10 (Home) while using 1.1.12 but not 1.1.11

[aaron777collins]

@aaron777collins the update process is really simple. You just need to overwrite the nvm.exe file in NVM_HOME. You don't need to use the updater at all. It's just a convenience program anyway.

That said, shells using unix paths aren't supported. Git bash uses unix paths like /c/path/to/whatever which Windows can't understand. Operating in git bash is akin to running NVM4W on Linux... which isn't going to work. Still, you should be able to move files around for an update. You just can't run most nvm <command> operations in a unix-like environment.

Thats very true, but would it be possible to disable this warning and let it run similar to 1.1.11? I'm okay with limited features. Could we maybe have a configuration file if we can't revert this feature? I'd ideally like to keep the software up to date using the updater but without the errors, Thanks!

[aaron777collins]

I coded a workaround in this PR by adding an ignore_terminal setting. Let me know what you think.

[sourcedelica]

I also ran into this bug using 1.1.12 with Git Bash, which we use for our CI jobs on Windows. I ended up switching to 1.1.11 to workaround it.

We run all sorts of Windows programs from Git Bash to compile our C++ code. It's rare that we run into any compatibility issues. If we do run into an issue it's usually an interactive program that gets keyboard input.

The different path structure in Git Bash only effects Windows apps if those paths are passed as input to the app somehow, like a command line parameter or an environment variable. Git Bash even tries to be clever, converting some CLI params and environment variables to Windows-style paths before running the program:

epederson@NAD4ZWN853 MINGW64 /c/work/llm-core (master)
$ python -c "import os; print(os.environ['PATH'])"
'C:\\Users\\epederson\\.krew\\bin;~\\bin\\Kui-win32-x64;C:\\Program Files\\nodejs;C:\\Program Files (x86)\\mitmproxy\\bin;
C:\\Go\\bin;C:\\Users\\epederson\\go\\bin;C:\\Perl\\bin;F:\\bin;C:\\Program Files\\Git\\mingw64\\bin;C:\\Program Files\\Gi
t\\usr\\bin...

[roo12589]

i used nvm1.1.12 by powershell7.4,it also happend. but it work well with powershell5, Is this not correctly recognizing the powershell7.4 I installed?

[aetonsi]

NVM breaks also if it does not detect an STDIN apparently, i think.
Or at least that's the problem i have

[o0101]

@aaron777collins the update process is really simple. You just need to overwrite the nvm.exe file in NVM_HOME. You don't need to use the updater at all. It's just a convenience program anyway.

That said, shells using unix paths aren't supported. Git bash uses unix paths like /c/path/to/whatever which Windows can't understand. Operating in git bash is akin to running NVM4W on Linux... which isn't going to work. Still, you should be able to move files around for an update. You just can't run most nvm <command> operations in a unix-like environment.

@coreybutler I respect that and I know you're super busy so sorry for pinging you, this will probably seem like a trivial non-issue, but this occurs even if 'escaping' the Git Bash environment using something like:

$ pwsh -Command "cmd.exe /C nvm"

which should be putting it in a normal Windows path environment, but we still get the box.

Surely what I'm about to say will seem like I could just do things another way, so I'm sorry to bug you with it because I know it's not your job at all to just fix all this stuff, but I have a bunch of bash scripts that mostly call into node and npm for setup related things, and they work on Git Bash.

If possible I'd love to avoid porting all these scripts over to pwsh, or whatever, but where they are breaking is when we use Windows nvm to set node versions.

For now I'm going to look for workarounds.

Anyway, no worries, I totally get if you're too busy to reply, no worries at all!

BTW - I love the box, I think it's a cool, iconic thing to add.

[o0101]

Found a workaround is to use: winpty (at least in GitBash):

cris@win-server MINGW64 ~
$ nvm 
# got box

cris@win-server MINGW64 ~
$ winpty nvm
# no box

Running version 1.1.12.

Usage:

  nvm arch                     : Show if node is running in 32 or 64 bit mode.
  nvm current                  : Display active version.
  nvm debug                    : Check the NVM4W process for known problems (tro
ubleshooter).
  nvm install <version> [arch] : The version can be a specific version, "latest"
 for the latest current version, or "lts" for the
                                 most recent LTS version. Optionally specify whe
ther to install the 32 or 64 bit version (defaults
                                 to system arch). Set [arch] to "all" to install
 32 AND 64 bit versions.
                                 Add --insecure to the end of this command to by
pass SSL validation of the remote download server.
  nvm list [available]         : List the node.js installations. Type "available
" at the end to see what can be installed. Aliased as ls.
  nvm on                       : Enable node.js version management.
  nvm off                      : Disable node.js version management.
  nvm proxy [url]              : Set a proxy to use for downloads. Leave [url] b
lank to see the current proxy.
                                 Set [url] to "none" to remove the proxy.
  nvm node_mirror [url]        : Set the node mirror. Defaults to https://nodejs
.org/dist/. Leave [url] blank to use default url.
  nvm npm_mirror [url]         : Set the npm mirror. Defaults to https://github.
com/npm/cli/archive/. Leave [url] blank to default url.
  nvm uninstall <version>      : The version must be a specific version.
  nvm use [version] [arch]     : Switch to use the specified version. Optionally
 use "latest", "lts", or "newest".
                                 "newest" is the latest installed version. Optio
nally specify 32/64bit architecture.
                                 nvm use <arch> will continue using the selected
 version, but switch to 32/64 bit mode.
  nvm root [path]              : Set the directory where nvm should store differ
ent versions of node.js.
                                 If <path> is not set, the current root will be
displayed.
  nvm [--]version              : Displays the current running version of nvm for
 Windows. Aliased as v.


cris@win-server MINGW64 ~
$ node -v
v21.5.0

cris@win-server MINGW64 ~
$ winpty nvm use v19
node v19.9.0 (64-bit) is not installed.

cris@win-server MINGW64 ~
$ winpty nvm list

  * 21.5.0 (Currently using 64-bit executable)

cris@win-server MINGW64 ~
$ winpty nvm install v19
Downloading node.js version 19.9.0 (64-bit)...
Extracting node and npm...
Complete
npm v9.6.3 installed successfully.

Installation complete. If you want to use this version, type

nvm use 19.9.0

cris@win-server MINGW64 ~
$ winpty nvm use v19
Now using node v19.9.0 (64-bit)

cris@win-server MINGW64 ~
$ node -v

v19.9.0

cris@win-server MINGW64 ~
$ node -p process.platform
win32

Also if you want node REPL just add winpty before node, like:

cris@win-server MINGW64 ~/BrowserBox (windows-install)
$ winpty node
Welcome to Node.js v19.9.0.
Type ".help" for more information.
> .exit

[johnrom]

That said, shells using unix paths aren't supported. Git bash uses unix paths like /c/path/to/whatever which Windows can't understand. Operating in git bash is akin to running NVM4W on Linux... which isn't going to work. Still, you should be able to move files around for an update. You just can't run most nvm <command> operations in a unix-like environment.

This project has worked perfectly in Git Bash for years as a foundational component of my Windows dev process by the way. If support for it was removed I would hope that a minor or major version bump would be used instead of a patch. As far as I know, Git for Windows' bash terminal translates C:\ and /c/ paths back and forth seamlessly in a way that made it inconsequential for a library like this (see https://www.msys2.org/docs/filesystem-paths/). It works perfectly for the install and use commands in 1.1.11.

Using winpty nvm * works in my case, although forgetting it causes problems that require using cmd / pwsh anyway. Rolling back to 1.1.11 resolves the issue.

[coreybutler]

@johnrom I'm glad it's working for you in Git Bash, but there won't be a any kind of version bump because Git Bash was never officially supported to begin with. If it does the translation automatically, that is truly awesome, and it's also news to me (because it didn't always do that).

As I've mentioned through the years, it is impossible for us to keep up with the nuances of every shell. They change more frequently than most people recognize. That's why we only support the shells that ship with Windows. This becomes the baseline... if something is compatible with CMD or PowerShell, it should be compatible with NVM4W.

That said, this issue was introduced because someone had NVM4W in their start menu, clicked on it, and it appeared to not work. The fix for this was introduced too hastily. I will either revert that change or merge one of the PRs that solve this issue for the next minor release.

[elynch93]

Seems like this is well-discussed already, but this caused nvm commands to just hang when being run by a GitLab CI runner (shell, powershell) since nothing was closing the dialog box that popped up. Figured I'd add a comment in case anyone else was having the same problems with NVM4W and GitLab. Guessing that the GitLab Runner is piping the output of the Powershell command somewhere which, as discussed above, caused the dialog box to pop up.

[eglove]

You're right to keep commenting. It's crazy how so many systems end up dependent on libraries like this that don't get much love update wise.

The more comments I see on a 2 month old critical issue like this, the more encouraged I am to find better supported alternatives.

Just an initial look around Volta seems to do the job and then some, probably a better option for teams. Far more active, maybe it's time to ditch the old port.

[reduckted]

@coreybutler I will either revert that change or merge one of the PRs that solve this issue for the next minor release.

Is there a timeline for this?

My preference is to revert the change. There's a PR (#1071) that adds an option to not show the message, but that still means the problem exists by default. This is a command line tool. Command line tools shouldn't open message boxes.

[majkinetor]

Happens to me in Windows terminal running powershell, had to revert to 1.1.11

[whitespacecode]

Having the same issue with. Will downgrade back to 1.1.11

[sambernet]

We also had to downgrade our provisioning tools to use an older version. Happens in Windows terminal, ConEmu but also regular PS terminals on our end. Also note it happens for both Windows PWSH (5.x) and PWSH Core (7+).

We reverted to 1.1.9 because we use the choco package, where the last published version before 1.1.12 was 1.1.9.

[sourcedelica]

By coincidence I'm also using chocolatey and I use `choco install -y nvm.install --version=1.1.11 --pin` to install 1.1.11.

…

-- Eric

On Mon, Feb 12, 2024 at 4:32 PM sambernet ***@***.***> wrote: We also had to downgrade our provisioning tools to use an older version. Happens in *Windows terminal*, *ConEmu* but also regular PS terminals on our end. Also note it happens for both Windows PWSH (5.x) and PWSH Core (7+). We reverted to 1.1.9 because we use the choco package <https://community.chocolatey.org/packages/nvm#versionhistory>, where the last published version before 1.1.12 was 1.1.9. — Reply to this email directly, view it on GitHub <#1068 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABAGGBHCCRJA4WXMOFN36IDYTKC5XAVCNFSM6AAAAAA7XRWTKCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMZZGYZDAMBVHA> . You are receiving this because you commented.Message ID: ***@***.***>

[coreybutler]

Folks, this will be addressed when I have time. I intend to revert the change.

For those who feel I'm not responding fast enough (like @eglove), please remember every version manager is supported by volunteers. If you want faster support, then signup for Runtime updates. That's my primary focus right now.

[AndreM222]

I tried to automate my setup of nvm and to be sure is installed I was running the nvm use to check if installed. If not than run the installer and recheck. But a problem is that if I want to add the values of the command into a variable then I get the error message as well.

[oryon-dominik]

Is there any quick workaround to fix this in automation?

[johnrom]

@oryon-dominik there are currently 2 options:

• Use a supported command line like powershell / command prompt in a supported environment (idk the specifics, some appear to have issues with Windows Terminal, so I would just say try using a different terminal if you don't depend on too many other terminal features)
• If using git bash, use winpty nvm [command]
• Roll back to 1.1.11

[johnrom]

I resolved this issue while preserving the warning popup functionality without adding any new command line arguments here: #1120

Only check terminal when there are no arguments, because it's possible the user clicked the .exe. If there are arguments, assume the user knows what they're doing. Add some launch tasks in .vscode to demonstrate the difference. The warning now indicates that if you are in an unsupported terminal, to try running nvm help instead.

[aaron777collins]

My PR that adds the ignore_terminal property (on by default to fix this) has now been fixed and should be merge ready. I'd love a review if y'all have time :) ?

[reduckted]

@aaron777collins If it's off by default, wouldn't that basically defeat the whole purpose of the check? Nobody would actually turn that check on. The reason it was added is here #1068 (comment):

That said, this issue was introduced because someone had NVM4W in their start menu, clicked on it, and it appeared to not work.

If this feature absolutely must stay, then #1120 from @johnrom seems to be the best fix.

[aaron777collins]

@aaron777collins If it's off by default, wouldn't that basically defeat the whole purpose of the check? Nobody would actually turn that check on. The reason it was added is here #1068 (comment):

That said, this issue was introduced because someone had NVM4W in their start menu, clicked on it, and it appeared to not work.

If this feature absolutely must stay, then #1120 from @johnrom seems to be the best fix.

That’s a fair point. I mainly implemented this because the automated scripts that my company uses stopped working with this feature. Thus, I created a feature flag to disable it. Originally I had it as opt-in to disable the feature but that wouldn’t help people much. Thus I swapped to have it ignore the terminal by default. #1120 seems to have a pretty good compromise. I’m happy as long as my bash scripts work again. Thanks!

[coreybutler]

The plan is to revert the changes. A new update is ready, but our code signing certificate got locked when I was trying to automate the process. As soon as I get this cleared up with the Cert Authority, I'll cut a new release. It may still be awhile though.

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days.

[reduckted]

Not stale