I am trying to use Run/Debug Configurations on WebStorm, however it doesn’t seem to source .zshrc and produces errors about not finding commands and environment variables. (An example of this would be yarn tauri dev
when using Tauri)
I have installed Ubuntu 20.04 in WSL and the project I opened in WebStorm resides under the $HOME directory. WebStorm is installed in Windows.
For the interactive shell, I have made zsh the default by chsh -s $(which zsh)
, but when using Run/Debug Configurations it uses the default non-interactive shell, which is dash as far as I know. And my environment variables and PATH are all set in .zshrc, which is not sourced by dash.
It seems in CLion, it is possible to execute commands in the login shell according to this YouTrack issue, but such an option is not available on WebStorm.
Is it possible to use zsh instead of dash as the default non-interactive shell? If not, it would help me a lot to know what is the best practice in such situations.
3
Answers
Thanks to the answer here and the discussion below, I was able to figure it out. (Thank you, @NotTheDr01ds and @lena.)
The main problem is that WebStorm is installed on Windows and therefore knows only the environment variables in Windows. There are two ways to solve the problem as follows.
Sharing WSL's environment variable to Windows through
WSLENV
.zshrc
so that it sets$WSLENV
when zsh starts.This runs WSL using zsh (logged-in and interactive), then runs powershell which brings you back to Windows. Although this doesn't seem to achieve anything, by going through zsh in WSL,
.zshrc
was sourced and therefore$WSLENV
set as well. You can check if it worked well by running the below command after you've run the above.When you run or debug any of the Run/Debug Configurations, you will see that the environment variable is shared successfully.
Setting the PATH in Windows
For most environment variables, the previous method works well. However, PATH is an exception. The Windows PATH is shared to WSL by default. The opposite doesn't work, probably because the PATH in WSL should not interfere with Windows.I've tried adding the
$PATH
of WSL into$WSLENV
but it didn't seem to work.In the end, what I did was manually adding each needed
$PATH
of WSL into the Windows PATH.For example, if there was
export PATH=$PATH:home/(username)/.cargo/bin
in.zshrc
, you can then add\wsl$Ubuntuhome(username).cargobin
to the Windows$env:Path
using the Environment Variable window.I might have made some mistakes, so feel free to leave an edit or comments.
You can try using
npm config set script-shell
command to set the shell for your scripts. Likenpm config set script-shell "/usr/bin/zsh"
.When
npm run <script name>
spawns a child process, theSHELL
being used depends on NPM environment. Cм https://docs.npmjs.com/cli/run-script:See also https://github.com/npm/npm-lifecycle/blob/10c0c08fc25fea3c18c7c030d4618a401963355a/index.js#L293-L304
There are several questions and points you make:
First, from the question title (and the summary at the end):
Well, maybe (using symlinks), but it would be a really bad idea. So many built-in scripts rely on
/bin/sh
pointing to Dash, or at least Bash. While Zsh might be compatible with 99.9% of them, eventually there’s a strong likelihood that some difference in Zsh would cause a system-level script to fail (or at least produce results inconsistent with those from Dash).It is possible in Ubuntu to change the default non-interactive ("system" shell) from Dash to Bash with
sudo dpkg-reconfigure dash
. If you select "No" in the resulting dialog, then the system will be updated to point/bin/sh
tobash
instead ofdash
.But not to Zsh, no.
I don’t run WebStorm myself, so I’m not sure on this exactly. Maybe @lena’s answer (or another) will cover it for you, but if it doesn’t, I’m noticing this doc page. It might be worth trying to specify Zsh in those settings, but again, I can’t be sure.
Hmm. I’m guessing you would need these set in a
.profile
/.zprofile
equivalent regardless. I would assume that WebStorm is executing the shell as a non-interactive one, which means that it wouldn’t even parse~/.bashrc
if Bash was your default shell.Best practice is probably to make sure that your
~/.profile
has any environment changes needed. Yes, this violates DRY (don’t repeat yourself), but it’s probably the best route.