-
-
Notifications
You must be signed in to change notification settings - Fork 3.2k
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
[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 18 v1.1.12 Failsv1.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:
***@***.***>
|
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. |
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. |
Is there any quick workaround to fix this in automation? |
@oryon-dominik there are currently 2 options:
|
I resolved this issue while preserving the warning popup functionality without adding any new command line arguments here: #1120
|
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 :) ? |
@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):
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! |
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. |
We can remove once this issue is resolved: coreybutler/nvm-windows#1068 Fixes #2
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 |
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
}
|
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
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: