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

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

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

I just noticed this issue today as well.

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

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

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.

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!

@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.

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.

# 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

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`}}"
}

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.

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 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!

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

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...

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?

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

@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.

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

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.

@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.

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.

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.

@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.

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

Having the same issue with. Will downgrade back to 1.1.11

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.

Not stale

Use that powershell script below
The alert "Terminal only", you should start a new process with terminal window;

# change node version
# keep same with .nvmrc version
# used for webstorm adding external-tools when before launch
# used for vscode when task dependsOn
if(Test-Path .nvmrc){
}else {
    echo "no .nvmrc file"
    return
}
$curVer = node -v
$curVer = $curVer -replace 'v', ''
$cfgVer = Get-Content .nvmrc
if($curVer -eq $cfgVer)
{
    echo "no need to switch version"
}else{
    # change version
    echo "change node version to $cfgVer"
    start powershell "nvm use $cfgVer"
    # wait 5 second for nvm process run to finish
    Start-Sleep -Seconds 5
}

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.

Not stale

Same issue when use nvm 1.1.12 inside jenkins pipeline on windows

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.

Go away stale bot. Had to downgrade.

Sorry to ping again. Someone else may need to comment. It's still marked stale.

Sorry to ping again. Someone else may need to comment. It's still marked stale.

I think the action runs daily, so it should remove the label in a few hours time.

@coreybutler any action here? This is still disrupting things for my team. I understand it's volunteer work but it's been 9 months since this post was made, and 6 months since the last update from you.

@coreybutler any action here? This is still disrupting things for my team. I understand it's volunteer work but it's been 9 months since this post was made, and 6 months since the last update from you.

And nearly 3yrs since anyone sponsored anything. As indicated in the Readme, updates will be posted to those who have subscribed, on twitter, and on our linkedin page. I've posted many updates on issues throughout the repo and I'm the wiki. The general gist is we're nearing a release of Runtime. Additionally, our code-signing cert was locked. We're in the process of acquiring a new one.

@lyonb96 workarounds are here: #1068 (comment)

@coreybutler any action here? This is still disrupting things for my team. I understand it's volunteer work but it's been 9 months since this post was made, and 6 months since the last update from you.

I'd recommend downgrading to the version 1.1.11 or checking out many people's recommended fixes. For example, I forked the repo and created a release where there's a setting to disable the verification. All of this won't matter when the cert lock gets lifted but in the meantime there's a lot you can do.

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.

Please consider one of the exempt options in https://github.com/actions/stale to prevent this issue from getting the Stale Stale label applied every 30 days.

@MikeMcC399 I've configured this a few times, without much success. I tried adding a new rule to prevent the bot from running on anything labeled not stale. Hopefully that will work.

As a general update for this issue, the code that caused this has been reverted. The main blocker now is code-signing the build.

Why is code signing a blocking problem?

If we do not code-sign new releases, Microsoft SmartScreen will prevent installation in most organizations.

How did this happen?

I tried to automate the build/code-signing process. Unfortunately, an uncaught error caused too many incorrect signing attempts, locking the certificate. I tried working with the issuer, but we never reached a resolution.

The code signing certificate is due to expire in November anyway, so I've been pursuing a new one. To summarize a long story, it's an expensive process riddled with barriers.

How is this being resolved?

I've been working directly with Microsoft to verify Author Software Inc., the new company I launched in July for this project. This entity will become the new steward of this project and its successor (Runtime). The verification program we're working with at Microsoft is only in a preview stage, so most of their efforts have to be done manually.

The good news is we've completed the identity verification steps. There are a few more steps before we can actually sign the apps, but it's nearly complete.

Once we regain the ability to code-sign, I'll cut a new release and close this issue.

@coreybutler while I wish you luck with Runtime and look forward to seeing what you add with it, that name for the software is going to be awful to search for...

@TheAtomicOption the executable will just be rt, so I suspect that's how people will search for it... if they search at all. It will be linked in the NVM4W help when it's ready.