[Issue]: nvm-update.exe: NVM for Windows should be run from a terminal such as CMD or PowerShell #1068
Comments
|
And now, after 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 |
|
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 That said, shells using unix paths aren't supported. Git bash uses unix paths like |
|
FYI @coreybutler I seem to get this issue even when attempting to run nvm from 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 # 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 18v1.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 Here is the style of azure-arm builder |
|
Further investigation, applying any kind of stdout redirect to nvm appears to trigger the dialog warning. From a So in any scenario where stdout is being redirected, either by this simple cmd example, or by |
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 |
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: |
|
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. |
@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: Also if you want node REPL just add winpty before node, like: |
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 Using |
|
@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. |
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 |
|
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:
***@***.***>
|
|
Not stale |
|
Use that powershell script below # 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. |
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. |
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) |
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
|
coreybutler
added
not stale
|
@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 |
|
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 |
and others
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.exeVersion
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
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:
But I have installed NVM...
The text was updated successfully, but these errors were encountered: