I have nodejs installed and I can access it in my default shell (bash).
The problem is that when I try to run a file it tries to open it with /bin/sh and thus it says /bin/sh: node: command not found
The problem disappears when I set in configuration run in integrated terminal as I have set the default shell for the terminal to bash.
How to change the default shell used in the code runner to bash so that I can run the file?
The only solution I found to your same problem is to make code runner run into the vscode integrated terminal.
My settings.json
"code-runner.executorMapByGlob": {
"*.ts": "ts-node --esm $fullFileName",
},
"code-runner.runInTerminal": true
In my case it stopped happening when opened vs code on bash, in that scenario code runner runs with bash, so probably you should take a look what starts the vs code and how.
If your problem is that sh doesn't have the same path as bash just add to the /etc/profile.d a file with the following code and should work:
if [ -n "${BASH_VERSION}" ]; then
# include ~/.bashrc if it exists
if [ -f "${HOME}/.bashrc" ]; then
. "${HOME}/.bashrc"
fi
fi
Related
I'm using VSCode and the official remote-ssh extension.
I would like to be able to write code /path/to/file in an ssh terminal or in the vscode integrated terminal in a remote window in order to open a file/folder in vscode remote.
I am aware that I can use code --folder-uri=vscode-remote://ssh-remote+ADDRESS/path/to/file from the local machine's terminal, but I want to be able to run a command from within the integrated vscode terminal and any other terminal session where I've ssh'd into the remote machine)
Currently, if I run code from a remote terminal it opens up a new vscode window on the remote machine.
To achieve this goal, in the past I've used the following alias on the remote machine:
alias code="${VSCODE_GIT_ASKPASS_NODE%/*}/bin/code"
Which looks for the code executable in ~/.vscode-server/bin/<COMMIT_ID>/bin before defaulting to the local /bin/code.
I got that alias from this related stackoverflow question.
However, this doesn't seem to work right now.
Upon closer inspection, it appears that there is no code executable in the vscode-server directory.
How can I fix this?
Both machines are running MacOS and visual studio code version f80445acd5a3dadef24aa209168452a3d97cc326, if that's relevant.
I also wanted to be able to run code from the integrated terminal when running VSCode with the "remote ssh" extension. In my case, the "remote" is a Linux box (named "aorus" below), and I want to use VSCode from a laptop running macOS (named "mbp").
As for you, I used to use the VSCODE_GIT_ASKPASS_NODE trick. Recently, I had to change the alias since code (or code-insiders in my case) wasn't available in bin/ anymore. It seems it has been moved to bin/remote-cli. The correct alias (tested with vscode 1.64.2):
alias code="${VSCODE_GIT_ASKPASS_NODE%/*}/bin/remote-cli/code"
If you also want this to work from other ssh sessions (not just inside the integrated terminal), you can create a short script that I called coder (r for "remote") which I have in ~/bin on my remote ("aorus"). Note that you need to be able to reach the local machine from your remote (I do that with Tailscale). The script looks like this:
#! /bin/bash
set -ex
remotehost=$(hostname)
localhost=mbp
cmd="code"
while [ $# -gt 0 ]; do
if [ -f "$1" ]; then
cmd+=" --file-uri \"vscode-remote://ssh-remote+$remotehost$(readlink -f "$1")\""
elif [ -d "$1" ]; then
cmd+=" --folder-uri \"vscode-remote://ssh-remote+$remotehost$(readlink -f "$1")\""
else
cmd+=" $1"
fi
shift
done
exec ssh $localhost -q -t -x "exec bash -l -c '$cmd'"
On my Mac, when running VSCode connected remotely to my Linux box, I can type this in the integrated terminal to open the file main.go present on my remote Linux box:
coder main.go
The reason I have to wrap code in bash -l is due to the fact that ssh, by default, runs in a non-login shell, which means that the ~/.bashrc on my Mac isn't picked up, meaning code isn't in the PATH. The error message looks like this:
bash:1: command not found: code
Another note: there is a shorter syntax documented here:
ssh -q -t -x mbp bash -l -c "code --remote=ssh-remote+aorus main.go"
I don't use this syntax is because this method isn't able to know whether you are opening just a single file (which should be open in the most recent VSCode remote session) or a folder (which should be open as a new VSCode remote session).
Finally, if you are using VSCode Insiders, you can create a symlink so that the command code works on your local machine (in my case, on my Mac):
sudo ln -sf /usr/local/bin/code-insiders /usr/local/bin/code
As already explained by maelvls the path has been changed.
But if you use it outside integrated terminal you will got message
Command is only available in WSL or inside a Visual Studio Code terminal
To avoid this you need to export VSCODE_IPC_HOOK_CLI in your .bashrc .
Use this script in your .bashrc
export VSCODE_IPC_HOOK_CLI=`ls -t /run/user/1012/vscode-ipc-* | head -n1`
alias code="~/.vscode-server/bin/*/bin/remote-cli/code"
If you want to open your file in your current visual studio use -r option.
code -r tes.txt
Note :
I can't call VSCODE_GIT_ASKPASS_NODE so I use full path, it is working well
I don't know if VSCODE_IPC_HOOK_CLI will show in different location, just check it in your integrated terminal visual studio code
tested on remote server Centos 7
local macOS Monterey version 12.2
Visual Studio Code Version: 1.64.2 (Universal)
Commit: f80445acd5a3dadef24aa209168452a3d97cc326
extension : remote-ssh
I am starting a new repo, thinking I should use the most recent Huksy v6 which is installed from LintStaged using their setup guide:
npx mrm lint-staged
// package.json updated with:
"husky": ">=6",
"lint-staged": ">=10",
This adds necessary packages and adds the husky files including the precommit files:
#!/bin/sh
. "$(dirname "$0")/_/husky.sh"
npx lint-staged
When i run my commit in the terminal it works fine. However, if I try to run my commit in GitHub Desktop or VSCode (which I know some teammates do), it results in an error for both:
npx: command not found. husky - pre-commit hook exited with code 127 (error)
I have npx installed:
npx -v
// 6.14.10
If I try to install in globall, such as described in other StackOverflow suggestions, it returns a warning about existing location (with & with out sudo):
ERR! EEXIST: file already exists, symlink '../lib/node_modules/npx/index.js' -> '/Users/plucks/.nvm/versions/node/v14.15.4/bin/npx'
npm ERR! File exists: /Users/plucks/.nvm/versions/node/v14.15.4/bin/npx
npm ERR! Remove the existing file and try again, or run npm
npm ERR! with --force to overwrite files recklessly.
Is there anything I can do so the programs like VSCode & GitHub Desktop can run?
I've got the solution from here. Hope you can find it as well!
https://typicode.github.io/husky/#/?id=command-not-found
https://github.com/typicode/husky/issues/912
Here it is, for clarity:
add a file ~/.huskyrc if you don't have one already
make sure it includes the following:
# ~/.huskyrc
# This loads nvm.sh and sets the correct PATH before running hook
export NVM_DIR="$HOME/.nvm"
[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"
As per this suggestion, adding the following to your pre-commit file should fix it:
export NVM_DIR="$HOME/.nvm/nvm.sh"
. "$(dirname $NVM_DIR)/nvm.sh"
export NVM_DIR="$HOME/.nvm"
a=$(nvm ls | grep 'node')
b=${a#*(-> }
v=${b%%[)| ]*}
export PATH="$NVM_DIR/versions/node/$v/bin:$PATH"
So the full file would look like this:
#!/bin/sh
. "$(dirname "$0")/_/husky.sh"
export NVM_DIR="$HOME/.nvm/nvm.sh"
. "$(dirname $NVM_DIR)/nvm.sh"
export NVM_DIR="$HOME/.nvm"
a=$(nvm ls | grep 'node')
b=${a#*(-> }
v=${b%%[)| ]*}
export PATH="$NVM_DIR/versions/node/$v/bin:$PATH"
npm run test
For husky>=6: update your .husky/pre-commit file to contain this:
#!/bin/sh
. "$(dirname "$0")/_/husky.sh"
export NVM_DIR="$HOME/.nvm"
[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"
npx lint-staged
This will find and expose the current node path and therefore npx path that you are using, which has been configured with Node Version Manager nvm
Before adding any modifications to your project try restarting your IDE as mentioned in this issue
I had to combine the answers of Cathal and Misol.
I did not want to edit the .husky/pre-commit like Cathal for two reasons:
I would need to that for every project I use husky in
It would actually break husky for my fellow developers on Windows
So I added a global ~/.huskyrc file like Misol did with the following contents:
export NVM_DIR="$HOME/.nvm/nvm.sh"
. "$(dirname $NVM_DIR)/nvm.sh"
export NVM_DIR="$HOME/.nvm"
a=$(nvm ls | grep 'node')
b=${a#*(-> }
v=${b%%[)| ]*}
export PATH="$NVM_DIR/versions/node/$v/bin:$PATH"
If you are working on a team with other people who may have installed nvm or node in slightly different fashion than you have, I would not recommend adding any export statements or edits to the $PATH in your .husky/precommit or ~/.huskyrc files.
If you want your VSCode to have proper access to the $PATH you expect from terminal you should always launch VSCode from terminal in the folder you are working from.
For example, in a terminal window:
~/_git/my_project: code .
Will launch VSCode with my_project open in a new window (it should remember your tabs and window state from the last time you worked on your project).
VSCode will now use the $PATH your terminal uses from your ~/.zshrc or ~/.bashrc, etc.
With this setup my .husky/precommit looks like this:
#!/bin/sh
. "$(dirname "$0")/_/husky.sh"
npx lint-staged
and my my .lintstagedrc.json looks like this:
{
"*.{js,jsx,ts,tsx}": [
"eslint --fix --debug --max-warnings=-1",
"npm run lint:prettier-fix"
],
"*.{css,less,sass,scss}": ["npm run lint:prettier-fix"],
"*.{g?(raph)ql,json,html,md,y?(a)ml}": ["npm run lint:prettier-fix"]
}
For those using fnm instead of nvm, adding the following to ~/.huskyrc worked for me:
eval "$(fnm env)"
Open VSCode settings and set the Inherit Env setting (Terminal > Integrated: Inherit Env) to false:
"terminal.integrated.inheritEnv": false
This setting enables or disables whether new shells should inherit their environment from VS Code.
I change code as the top answer says. But it doesn't works at first, and then reopen VScode and it works.
In the terminal, I input these commands:
copy this command in terminal and press enter.
vi ~/.huskyrc
copy this command in terminal.
export NVM_DIR="$HOME/.nvm" [ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"
input :wq to quit edit state
reopen VScode.
I have pyenv installed, however, it does not do its most basic function, namely switch Python versions. The following terminal commands demonstrate this.
the file `main.py` is equivalent to:
import sys
print (sys.version)
Admins-MacBook-Pro-4:kylefoley kylefoley$ pyenv versions
system
* 2.7.14 (set by PYENV_VERSION environment variable)
3.5.3
3.6.1
3.7.3
pypy3.6-7.1.1
Admins-MacBook-Pro-4:kylefoley kylefoley$ pyenv global 3.5.3
Admins-MacBook-Pro-4:kylefoley kylefoley$ pyenv exec python main.py
2.7.14 (default, Oct 17 2019, 00:01:43)
As you can see when I run main.py the version that comes out is 2.7. A lot of people have this problem. One common solution is putting
eval "$(pyenv init -)"
On the bash_profile which I have done and that did not help. Over here
Cannot switch Python with pyenv
it is recommended:
Put the PATH and shell environment vars into your .bash_profile (or whatever file your distro uses).
But what PATH and what shell environment vars is he talking about?
Also my .bashrc file looks like this:
export PATH="/Users/kylefoley/.pyenv/bin:$PATH"
eval "$(pyenv init -)"
eval "$(pyenv virtualenv-init -)"
Any help would be appreciated. One other things, when I run the following commands, I get the following output:
Admins-MacBook-Pro-4:kylefoley kylefoley$ python
Python 3.6.1rc1 (default, Mar 4 2017, 22:58:58)
The problem is that .bashrc is not sourced in a non-login mode.
Init files for Bash:
login mode:
/etc/profile
~/.bash_profile, ~/.bash_login, ~/.profile (only first one that exists)
interactive non-login:
/etc/bash.bashrc (some Linux; not on Mac OS X)
~/.bashrc
non-interactive:
source file in $BASH_ENV
And on macOS, the default Bash shell opened by a terminal app is a interactive login shell, but on Linux, the default shell opened by a terminal app is a interactive non-login shell.
Solution
The weird interactive, non-login loading requirement confuses people in other situations as well. The best solution is to change the loading requirement of ~/.bashrc as interactive only, which is exactly most of the Linux distros are doing.
# write content below into ~/.bash_profile
# if running bash
if [ -n "$BASH_VERSION" ]; then
# include .bashrc if it exists
if [ -f "$HOME/.bashrc" ]; then
. "$HOME/.bashrc"
fi
fi
This should be the solution you desire. And I recommend every Bash user setup this in the profile.
References
Unix shell initialization
Everything was done correctly, it's just that I thought the terminal command . ~/.bash_profile updates the bash profile without having to close the terminal or open a new one in order for changes to take effect. It turns out that . ~/.bash_profile only updates some of the bash_profile. After restarting the terminal, everything was working as planned.
Just add to your .bashrc or similar file, the line.
eval "$(pyenv init --path)"
After the "export PATH=$PYENV..." . Don't forget to reset your terminal after try again!
Worked on Fedora & Mint.
Just add this into you .bashrc file:
export PYENV_ROOT="$HOME/.pyenv"
export PATH="$PYENV_ROOT/bin:$PYENV_ROOT/shims:$PATH"
If your .bashrc is sourced from ~/.bash_profile you are done.
Official docs https://github.com/pyenv/pyenv#advanced-configuration suggests puting into .bashrc:
eval "$(pyenv init -)"
which was not working for me.
1.) configure:
pyenv global [python version]
2.)restart terminal (close all terminal windows)
When I try to execute code from WSL, like this:
cmd.exe
wsl code .
I get the following error:
/bin/bash: code: command not found
However, if I execute the same command but first run cmd.exe as an Administrator, vscode opens as expected.
The question is why "code" is not recognizable when I run as non-admin, and how can I solve it?
Additional info:
WSL2 version 41959
vscode version 1.38
vscode Remote WSL extension version 0.39.5
As #Biswapriyo mentioned, this is an open bug where WSL cannot access Windows C drive.
Workaround that helped me is to restart WSL like this:
wsl --shutdown
wsl
Open the PowerShell administrator window
wsl --list --version
Show as wsl 2
Enter the Linux console
wsl
Change related files' rights
chmod u+x vscode_dir/code.exe
chmod u+x vscode_dir/bin/code
Create symbolic link
ln -s vscode_dir/bin/code code
mv code ~/.local/bin
Modify .bashrc, add a line as follows:
export PATH="$HOME/.local/bin:$PATH"
source .bashrc or restart terminal.
Then you can happily play code in wsl2-ubuntu environment or terminal of VSCode.
My problem was that I was using the root user after running sudo -i. Exiting and using my normal user on WSL solved the error.
In my case I am using Debian and echo %PATH% did not output anything.
I used the second part of suggested solution from resolved github issue
For Debian, /etc/profile contributed to this problem.
Here is the path definition in /etc/profile
if [ "`id -u`" -eq 0 ]; then
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
else
PATH="/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games"
fi
Option 1:
You can delete above lines, then wsl --shutdown to restart Debian.
Option 2:
If you would like to keep these lines, you can also append ":$PATH" to each path like below, then wsl --shutdown
if [ "`id -u`" -eq 0 ]; then
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:$PATH"
else
PATH="/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:$PATH"
fi
Thank you to licanchua
I'd recommend checking /etc/wsl.conf to see if appendWindowsPath setting shares the Windows PATH with WSL, and also if it is specifically setting a particular user.
For the config settings, see https://learn.microsoft.com/en-us/windows/wsl/wsl-config
I've created aliases in c:\Users\user\.bash_profile and in C:\Program Files\Git\etc\profile.d\aliases.sh but both configs getting ignored by VSCode integrated terminal, which is configured to use git bash:
"terminal.integrated.shell.windows": "C:\\Program Files\\Git\\bin\\bash.exe",
if I open GitBash itself - aliases works fine
how do I force integrated terminal to respect the configs?
You can try adding to the settings:
// The command line arguments to use when on the Windows terminal.
"terminal.integrated.shellArgs.windows": [
"--login", "-i"
],
-i - force the shell to run interactively.
--login - make this shell act as if it had been directly invoked by login. When Bash is invoked as an interactive login shell, or as a non-interactive shell with the --login option, it first reads and executes commands from the file /etc/profile, if that file exists. After reading that file, it looks for ~/.bash_profile, ~/.bash_login, and ~/.profile, in that order, and reads and executes commands from the first one that exists and is readable.
When invoked as an interactive shell with the name sh, Bash looks for the variable ENV, expands its value if it is defined, and uses the expanded value as the name of a file to read and execute. Since a shell invoked as sh does not attempt to read and execute commands from any other startup files, the --rcfile option has no effect. A non-interactive shell invoked with the name sh does not attempt to read any other startup files.
Read more.
As an alternative you can use the .bashrc file instead of .bash_profile.
The solution using the "--login" and "-i" shell arguments did not work for me. What did work was using the bash "-rcfile" shell argument, like this, in my settings file:
"terminal.integrated.shellArgs.windows": [
"-rcfile",
"c:\Users\\.bash_profile", ],
... where <userid> is my Windows userid and the alias commands are in a file called ".bash_profile" that is located in c:\Users\<userid>
I simply switched to my root user directory c:\Users\user then ran source .bashrc. This did the trick on my machine, hope it helps.
Create .bashrc in c:\Users\username
Add an alias, e.g alias gotossh="cd /c/users/username/.ssh"
In your terminal, run source .bashrc while in c:\Users\username
Confirm that the alias works by running alias
You might not have a .bashrc file in the users folder which is important to note.
Also remember to write the paths correct and don't leave any space between the equals in e.g alias="somecommand"
As of 2020 there is no need to add the shellArgs.