Git Bash for windows not working properly - node.js

I am having a very annoying issue with git bash for windows.
When first lauching git bash, everything works fine, but after I type in node -v to check the nodejs version, nothing is returned and every subsequent text I type in is not displayed (although when pressing enter these commands' outputs get displayed).
In the image below I ran the commands in this order:
- node -v (no output)
- npm -v (no input displayed)
- git --version (no input displayed)
Image showing the problem
Everything started with a SIGFAULT error when running any node or npm command. After unninstalling git for windows and installing again, it is working like this.
But, when I use the bash as a attached terminal for vscode, I get these errors in every command I run:
Attached terminal throwing Segmentation fault error
How can I solve it?

Related

Ionic command not working only in Git Bash

Whenever I try to use ionic command in Git Bash, I get a "command not found" error. But when I test this command in Powershell or CMD, it works. It's only in Git Bash where it doesn't work.
This worked fine earlier, but then stopped working after downgrading my node to v13.13.0 and npm to v6.12.1.
This is the complete error:
C:\Users\Administrator\AppData\Roaming\npm/node_modules/node/bin/node: line 1: This: command not found
And what I also realized about this file path is that it used both "\" and "/" symbols instead of sticking to only 1. I made sure to check my environment variable path if it's set correctly, and also restarted my Git Bash but the error still persists.

"Locust command not found" returns even after I have installed Locust on Ubuntu

I have installed locust using the pip command and when I move forward towards verifying the installation using this command: locust -v , it throws the following line back: Command Not Found
Secondly, when I installed Locust, some statements showed up on console as can be seen in the image below.
The message in yellow is the problem. Add that directory to your PATH variable.
export PATH=/home/purelogics/.local/bin:$PATH
After updating path, locust -V will work as expected.

Unable to run node from git bash

I am no longer able to run node from the git bash terminal. It works from Git CMD and the standard windows CLI. If I try to run a file (e.g. node index.js) or even just start node via node, I go back to the input prompt except now I can't see any of my character inputs.
This is not a result of PATH not being set, as where node gives me C:\Program Files\nodejs\node.exe and which node gives me /c/Program Files/nodejs/node and echo $PATH does have /c/Program Files/nodejs included.
If I type another command (such as ls), it actually will work even though I will continue to not be able to see my input.
I think this problem arose after the latest Windows 10 OS update was pushed to my system (10.0.17763). I've tried reinstalling Git for Windows and Node, and neither have resolved the issue. I can't find any other settings that might be affecting this.
Using Git CMD or Windows CLI is a workaround, but neither of those have a "Git Bash Here" option, which is the #1 thing I want this for. It is also nice that I get the visual indication of branch in Git Bash where I do not get that with Git CMD or the Windows CLI.
I don't need or want to use Git GUI, and besides that won't allow me to run local node files which I need to do for testing.
Does anyone have any ideas on how I can get Git Bash working with node again?
UPDATE: By running stty -a after node fails, I see that echo has flipped to -echo, which is why I can't see the input anymore. But that doesn't explain why node isn't loading and echo is getting turned off. Hoping that gives someone some additional context to figure out what's going on here. brkint, icrnl, ixon, opost, isig, and icanon are also getting flipped to the - versions after attempting to run node.
There are 2 possible workarounds (based on what your problem is) that I have tried-
Enter node first of all:
1) Try typing in reset and hit enter. You may not be able to see the input logging in, in the bash terminal window, but it works after that.
2) Or try typing any random alphabet and hit enter(again you won't see it on the screen),it will throw a 'command not found' error but you will have node working after this.
I am afraid these aren't exactly proper fixes, but they get the job done.
More information can be found here: https://askubuntu.com/questions/171449/shell-does-not-show-typed-in-commands-reset-works-but-what-happened/172747#172747

Autorest fails to generate anything, and no error

I am trying the petshop client generation example on github and autorest just exits without creating anything or throwing any errors. Autorest behaves like I did not pass any arguments. Attached is a screenshot of my powershell execution.
Try executing your same command but add --verbose at the end to tell autorest to print out any errors.
I was experiencing the same problem and what worked for me was creating the following readme.yml file and simply running the command
autorest readme.yml
With those two things (readme.yml and the command) I was able to generate the code in csharp without any issues.
Image of Readme.yml for csharp code generation:
For me what finally worked was:
Install the latest Node from https://nodejs.org/
Go to C:\Users\%userprofile%\AppData\Roaming\npm and delete the 2 autorest files there if you have them.
Open a Command Prompt (type cmd in the address of any Windows folder)
In the Command Prompt type this command:
npm cache clean -f
Now, also in the same Command Prompt, type this command:
npm install autorest -g
You should now be able to generate your client.
This answer on GitHub repo of Autorest, suggest that you execute
autorest --reset
after updating. It removes older plugins of Autorest. I had the same problem (without updating Autorest) and it has solved after that.

Jenkins build step fails when calling "npm" on mac-os-x Yosemite

Before I start, I want to say that I already checked these answers:
Jenkins build step fails on 'npm install <whatever>'
Jenkin's build failing on npm install
Now, I'm dealing with this issue for a while already and thus I tried a bunch of stuff.
Firstly, I installed node + npm via homebrew. A simple $ node -v and $ npm -v echoed the version v0.10.36 for node and v2.3.* for npm, which also means I HAVE THEM IN THE PATH and they work while called in the terminal.
Simply adding node -v; npm -v to the execute shell in Jenkins didn't do it. After a bit of tinkering I copied what $: which node yielded in the terminal to the above mentioned script, which now looked like this: /usr/local/bin/node and apparently that worked. The Jenkins build succeeded and 'node-v0.10.36' was proudly displayed in the console output.
When doing the same for 'npm' which happened to be /usr/local/bin/npm --version the computing gods weren't so merciful anymore. A big 'env: node: No such file or directory' error was thrown this time and the whole build failed.
The actual command that fails is
$ /bin/sh -xe /var/folders/wr/g_dl81tn5_x0t_yz3jw602cr0000gn/T/hudson8770480548136671253.sh and "surprisingly" when I run the same command in the terminal it succeeds.
I also uninstalled the homebrew node & npm versions and installed them afterwards via the package manager. Same results.
Ultimately I also did this: https://gist.github.com/DanHerbert/9520689, with no luck.
Notes:
I'm running Jenkins 1.613 and tried with 1.5**
I didn't create a "Jenkins" specific user but instead I'm using the admin. This happens to be the same user that Jenkins runs, since the who am i command inside the executable script yields the admin's user name.
sudo'ing doens't help
I'm also running the whole thing in a Virtual Environment - vagrant
I'm not running Jenkins as a deamon, as it's conflicting with xtools, but as a simple process
I also tried out jenkins-node plugin with various configs (can detail if needed)
Thanks a lot for your help, and let me know if you need any other info, screenshots, logs, etc.
I found my own solution. The problem was that the PATH although visible in shell was not exported for the Jenkins job, and so, the first workaround, as found here, was to export it in the actual script like so:
but this feels like a hack!
The right and elegant solution is to use Jenkins EnvInject Plugin and export the path in the added Properties content textarea on the configuration page, like so:
Manage Jenkins -> Configure System -> Global properties -> Environment variables

Resources