Inside my WSL2 environment I have adb added to the Path env variable. I want to invoke it directly from Windows CMD like so: wsl adb, but I receive the following error:
zsh:1: command not found: adb
It's as if it doesn't source ~/.zprofile when it runs the command and thus doesn't have the adjusted PATH variable. Any ideas how to deal with this? ZSH is the default shell inside my WSL2 environment and running adb from inside it works just fine.
I figured it out, this seems to work: wsl zsh -ic "adb"
Related
I'm using the most recent VScode on Ubuntu 22.10 and experiencing the following issues while opening ZSH and BASH shells in the integrated terminal. The standard Ubuntu terminal works without errors.
After starting a ZSH integrated terminal:
compdump:138: command not found: mv
/home/user/.oh-my-zsh/oh-my-zsh.sh:56: command not found: mkdir
/home/user/.oh-my-zsh/tools/check_for_upgrade.sh:29: command not found: git
/home/user/.oh-my-zsh/oh-my-zsh.sh:115: command not found: rm
getent:6: command not found: grep
_p9k_init_cacheable:59: command not found: uname
_p9k_init_cacheable:61: command not found: uname
BASH
Command 'uname' is available in the following places
* /bin/uname
* /usr/bin/uname
The command could not be located because '/bin:/usr/bin' is not included in the PATH environment variable.
uname: command not found
Just several hours before, it worked just fine. Then I tried to set up Remote SSH to another Linux machine (Fedora 36, with the same sort of errors I was also unable to resolve by googling).
Using the #modified keyword in Settings, I ensured that no unexpected changes had been made. The PATH is the same as in the fully operational standard terminal.
Wondering what could be the issue.
UPDATES.
PATH variable:
/usr/local/cuda-11.7/bin:/home/user/.conda/envs/env/bin:$PATH
The problem.
Unlike the complete PATH expansion in the standard terminal, PATH was expanded partially (omitting /usr/bin, etc.) in the integrated terminal.
Based on this error,
The command could not be located because '/bin:/usr/bin' is not included in the PATH environment variable.
I suggest you run,
export PATH="/usr/bin:$PATH"
To add /bin:/usr/bin to your PATH
Having :$PATH in your PATH means that the sheell will add the variable $PATH to the end of your PATH
The cause of the issue the following configuration from the User settings:
terminal.integrated.env.linux": {
"PYTHONPATH": "/media/user:/media/user/common:$PYTHONPATH",
"PATH": "/media/user:/media/user/common:$PATH"
}
While the PYTHONPATH variable is expanded properly in the integrated terminal, the PATH is expanded partially to something shown in the UPDATES section of the question. To build on top of the answer by #Orion447, looking for any potential place where PATH could get corrupted is the approach that likely solves the problem.
I'm running Ubuntu-20.04 through WSL2 on my Windows 10 laptop. I've started having an issue in VSCode where the integrated terminal isn't getting its $PATH initialized correctly.
If I open an Ubuntu shell through Windows Terminal and run echo $PATH I get the following output:
/home/<user>/bin:/home/<user>/.nvm/versions/node/v15.1.0/bin:/usr/lib/jvm/java-1.11.0-openjdk-amd64/bin:/opt/devkitpro/tools/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/mnt/c/Program Files/Common Files/Oracle/Java/javapath:/mnt/c/Program Files (x86)/Common Files/Oracle/Java/javapath:/mnt/c/WINDOWS/system32:/mnt/c/WINDOWS:/mnt/c/WINDOWS/System32/Wbem:/mnt/c/WINDOWS/System32/WindowsPowerShell/v1.0/:/mnt/c/WINDOWS/System32/OpenSSH/:/mnt/c/Program Files (x86)/ATI Technologies/ATI.ACE/Core-Static:/mnt/c/Program Files (x86)/AMD/ATI.ACE/Core-Static:/mnt/c/Program Files (x86)/Calibre2/:/mnt/c/Program Files/Calibre2/:/mnt/c/Program Files/PuTTY/:/mnt/c/Program Files/FileBot/:/mnt/c/Users/<User>/AppData/Local/Microsoft/WindowsApps:/mnt/c/Users/<User>/AppData/Local/Programs/Microsoft VS Code/bin:/snap/bin
However once connected to WSL through VSCode if I run the same command in the integrated terminal I get:
/home/<user>/.local/bin
This means I can't even run the most basic commands like ls.
I can't understand why this is happening? Is there some setting in VSCode that would be interfering with my shell initialization, preventing $PATH from getting set correctly? I can't even run env to see what other environmental variables are doing.
The default shell in VSCode is set to bash.
It is my understanding that bash reads instructions from /etc/profile which sets shell variables. Could there be any reason these instruction are not being read?
Ok so I figured out what was causing the issue.
In my .bashrc, I had added the line:
export `PATH="/home/<user>/.local/bin"`
presumably to be able to access programs located there from any directory. For whatever reason this wasn't causing an issue when a shell was launched from Windows Terminal, but VS Code did not like it! Simply removing the aforementioned line from .bashrc solved the problem.
Guess I've got a lot to learn about .bashrc, .bash_profile, etc., and how these are accessed when starting up a bash shell. If anyone wants to shed light on this, feel free to comment below.
Problem
When I run a bash script on Windows:
bash my_script.sh
I get linux-gnu for $OSTYPE inside the script.
Why is this like this?
I assume that i have WSL installed is relevant here.
Tested in PowerShell and CMD.
Git bash is returning msys like expected! Thx #user1934428
Background
I want to start some python scripts from bash, but not inside WSL.
From my command line I reach different python versions on windows, but from inside the bash scripts it is using the one inside WSL (except for GitBash).
You're right, running the bash command in PowerShell or CMD will launch WSL to run your script. You confirm this (and see which version of WSL) by running cat /etc/issue in your bash script. Your WSL environment will have an independent set of environment variables (not just $OSTYPE). You can see this by comparing the output of Get-ChildItem -Path Env:\ in PowerShell to the output of env (after you launch bash from PowerShell).
I suspect that the python version discrepancy you're seeing is a result of the PATH variable in your WSL runtime not matching what you have set in your PowerShell environment. You can fix your version issue by setting an alias containing a path to the python executable you want to use by adding alias python=/c/path/to/python.exe to the start of your bash scripts.
Alternatively, you can use a tool like Cygwin or git-bash to run your scripts. I'm not sure if they will use the same path variables as Windows so you may need to set those manually too.
I realise there are a few questions similar to this but nothing that fully addresses the issue I'm getting.
I'm writing a few alias' for terminal commands I often use.
$ cd ~/Documents/blah/blah/blah
This works as a terminal command, but when I try to turn this into an alias:
alias pie='cd ~/Documents/blah/blah/blah'
This doesn't work, -bash: cd: Documents/blah/blah/blah: No such file or directory
I'm storing the alias in .bashrc in my home directory. I'm using Mac OSX.
Anyone know why it would work as a straight command but not an alias?
Similarly, I use a vagrant machine, and I'd like the chain together two commands: one to ssh to vagrant and the other to open the shell:
alias vshell='vagrant ssh && python manage.py shell
But this doesn't seem possible, it only ever executes the first command, maybe because this takes a little longer to complete?
Thanks
I have no trouble starting my meteor server from the terminal window. But surely I can do this from a shell script that I make with Automator. This is what I do in the terminal window:
cd myAppName
meteor
For the the automator shell script, I change the directory differently:
cd /Users/myName/myAppName
... and that seems to work fine. But the next line gives a "meteor --command not found" message. I read somewhere that the shell that automator runs doesn't have access to the Environment variables that the terminal window uses. That must be the problem. So how do I run meteor from the shell script?
Try setting the PATH variable from inside your script. It should include the directory path to your meteor executable.
It should be something like:
export PATH=$PATH:/opt/meteor/bin/meteor
After that meteor should launch. If meteor starts launching but it fails then you're missing more environment variables inside your script and you must export them as you did with the PATH.
To know which environment variables you have in your shell type this:
set