So I have two WSLs (version 2). Kali and Ubuntu. The code command works in Kali but Ubuntu says Command not found. Since it works in WSL, CMD and PowerShell, it is there in PATH variables. Any help?
edit: Ubuntu doesn't read VS Code in PATH variables, while Kali does. I opened the Environment Variables Wizard. VS Code is there.
In a "normal" case, like you are seeing in your Kali instance, WSL's init appends the Windows path to your Linux path. There are two things that I can think of that would cause that to not be happening correctly under your Ubuntu instance:
You or a script that you ran in Ubuntu modified your shell's startup files (assuming Bash, typically ~/.bashrc or ~/.profile) to edit the PATH, possibly removing the Windows elements, or at least the VSCode element.
Try running that instance without any Bash startup files (from PowerShell or CMD) with:
PS> wsl -d Ubuntu -e bash --noprofile --norc
and then try code .. This, of course, assumes that your Ubuntu instance is named Ubuntu. If it's named something else (wsl -l) then edit the -d Ubuntu as needed. You might also try launching it as wsl -d Ubuntu -e sh -c 'code .'
If that works, examine your startup files for any modifications to PATH.
Less likely (because you should know if you did this one), is that you can disable the WSL feature that appends the Windows PATH in a particular distribution/instance. Check for the existence of a /etc/wsl.conf file -- If it exists, the line appendWindowsPath=false would cause the behavior that you are seeing as well. Simply change the offending setting to true. Exit your Ubuntu instance, run wsl --terminate Ubuntu (again, substituting the correct distro name) and then restart. Check your PATH and try code . again then.
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 have this message whenenver i try to type code .
Can someone help me please ?
Thanks in advance
Fixed it
Open VS Code on Windows
Open Extensions and then search on WSL
It should say the extension needs to be reloaded - go ahead and reload it
Open WSL and type code
This should force another upgrade of code and this time it should launch.
I just now had the same issue on WSL2 Kali. I tried everything given here: https://github.com/microsoft/vscode-remote-release/issues/2962.
My problem was VS Code was not on Kali's path. Here's how I fixed it :)
echo $PATH
# Confirm PATH is missing this:
/mnt/c/Users/wcd/AppData/Local/Programs/Microsoft VS Code/bin/
# Confirm VS Code's location then export:
export PATH=$PATH:"/mnt/c/Users/wcd/AppData/Local/Programs/Microsoft VS Code/bin/"
# It's temporarily added to path...
echo $PATH
# This should now trigger VS Code Server install,
# then open ~/ in VS Code.
code .
# If above works, make it permanent:
echo 'export PATH=$PATH:"/mnt/c/Users/wcd/AppData/Local/Programs/Microsoft VS Code/bin/"' >> ~/.bashrc
# Restart shell + test
exec "$SHELL"
code .
I solved this problem by opening windows powershell in admin mode and typing the following command:
wsl --update
Then I typed this command to force restart the WSL and all done
wsl --shutdown
I have same issue when I trying export my old wsl and move whole project to nvme ssd using new distro.
I able to run the code . on root , but when i switch to my name then it doesn't work, I guess is WSL PATH problem.
I not really familiar to the linux, the below image may easier for you to understand what i am saying.
When i use echo $PATH on wsl to compare root and my account, and i notice that VS code directory only found on root instead of my account.
So i use export PATH=$PATH:"/mnt/c/Users/ricso/AppData/Local/Programs/Microsoft VS Code/bin" to add the VS Code path to my account* and code . is working once i export this.
But the code . will not be able to run again if you restart the wsl, so we need to put in to bashrc.
But when i try to update my account's* PATH using
echo "PATH=$PATH:/mnt/c/Users/ricso/AppData/Local/Programs/Microsoft\ VS\ Code/bin" >> ~/.bashrc and restart the wsl to login my account, i notice an error msg popup when run the code .
cannot create /tmp/remote-wsl-loc.txt: Permission denied
And i found this.
https://github.com/microsoft/vscode-remote-release/issues/5389
Seem they only giving the workaround for now and hopefully can fix it soon.
*disclaimer above: this code need to run under your account instead of root
**For editing bashrc, instead of using echo and >> write to the file, you also can use code ~/.bashrc to update/edit, when you have the vscode access on wsl.
This also happens if you disable the Windows PATH on WSL. I had my VS Code working fine, then when I disable the windows PATH (by editing/creating the /etc/wsl.conf file and inserting the [interop] appendWindowsPath = false parameter) the code command stopped working.
The ek1n8 solution solves my problem, addind the export manually to the WSL Path:
export PATH=$PATH:"/mnt/c/Users/%USERNAME%/AppData/Local/Programs/Microsoft VS Code/bin"
For me adding the binary to Path was enough:
export PATH=$PATH:"/mnt/c/Users/%USERNAME%/AppData/Local/Programs/Microsoft VS Code/bin"
For me it was wsl using the wrong container:
wsl --list -v
NAME STATE VERSION
* docker-desktop-data Stopped 2
Ubuntu Running 2
I did wsl -s ubuntu
wsl --list -v
NAME STATE VERSION
* Ubuntu Running 2
docker-desktop-data Stopped 2
and it solved the problem
I have an Ubuntu-18.04 WSL instance installed and have a large set of scripts installed in it at /home/username/bin/scripts.
I have also updated the $HOME/.bashrc, $HOME/.bash_profile, /etc/bash.bashrc, /etc/profile and /etc/environment files to update $PATH to include /home/username/bin/scripts in the path.
*I'm well aware i only usually need it in my $HOME/.bash_profile, lots of places from experimenting
Say I have a script called sampleScript in /home/username/bin/scripts, when i try to run the command:
wsl sampleScript
It gives the error: /bin/bash: sampleScript: command not found
If I open up wsl in interactive mode I can run it just fine, but I would like to be able to expose the script to not be run in interactive mode.
I've tried making an environment variable SPATH='/home/username/bin/scripts' and setting WSLENV=SPATH/p, but it also does not show up if i do wsl echo $PATH.
*I'm doing this all in command line instead of powershell b/c powershell doesn't appear to be able to do wsl echo $PATH at all, it just returns empty
I have also tried: wsl -u username sampleScript; with no luck
Is there a way to customize the PATH for wsl interop mode or am i doing something incorrectly with WSLENV?
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 have been trying to pip install psycopg2 for some time now
I have just updated to python 3.7.4, before this problem started.
To set my path to a specific python version I used the code below.
nano .bash_profile
I thought that it would now be easy for my system to identify the path of the newly installed python, as to enable it to install psycopg2. Then the below started happening.
The second line of system terminal or python terminal is now always showing:
-bash: zzzzz#: command not found on my terminal
No matter what I type on my terminal, I am always getting command not found
This would mean you literally have "zzzzz" somewhere in the bash_profile. Bash is seeing "zzzzz" as just another command to run at startup like the rest of the profile script. As there is nothing in your PATH matching that string, bash reports the issue back to you.
Either remove the extra line from your .bash_profile. OR use a terribly wasteful work-around!
ln -s /bin/true /bin/zzzzz
This will create a symbolic link to the "true" binary (all it ever does is return true) from zzzzz. Now bash can find zzzzz and run it during start up, which does nothing. No more error and an absurd work around. You should fix the file.