I recently had to reinstall my system and ever since I've been having a weird issue with tmux where it prompts me for my sudo password every time it creates a new pane or window (including when I first start it). It appears to make absolutely no difference whether I actually enter it or not; because the prompt happens after the pane/window was already created, I can just Ctrl-C out of the prompt if I want. I’m not sure if more functions are also affected which I just don't use but at least some of those I do use are definitely not (e.g. source-file).
On a sidenote, I also noted that since I changed my login shell to zsh after the reinstall, alias definitions in .zprofile do not carry over to interactive shells anymore, which they definitely did do under my previous system (although the file is definitely sourced as environment variables are set correctly even in the interactive shell). Maybe my shell environment got messed somehow and the tmux problem is just a side-effect of that?
Never mind, I found the issue: I was using a sudo call to start a daemon in my .zprofile, so when the interactive shell sourced that it caused a sudo prompt. I found a workaround which doesn't require sudo which solved the problem.
Related
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.
There are several questions and points you make:
First, from the question title (and the summary at the end):
Can I use zsh as the default non-interactive shell for WSL2 Ubuntu?
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 to bash instead of dash.
But not to Zsh, no.
when using Run/Debug Configurations it uses the default non-interactive shell, which is dash as far as I know
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.
And my environment variables and PATH are all set in .zshrc, which is not sourced by dash.
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.
... it would help me a lot to know what is the best practice in such situations.
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.
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
Add the line below to .zshrc so that it sets $WSLENV when zsh starts.
export WSLENV=VAR_I_WANT_TO_SHARE:$WSLENV
# Don't forget to insert the colon
# And for some reason, appending the variable after $WSLENV didn't work well
In Windows, run
wsl -e zsh -lic powershell.exe
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.
$env:VAR_I_WANT_TO_SHARE
Run WebStorm from the PowerShell that was just created.
& 'C:\Program Files (x86)\JetBrains\WebStorm 2022.1.3\bin\webstorm64.exe'
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$\Ubuntu\home\(username)\.cargo\bin 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. Like npm config set script-shell "/usr/bin/zsh".
When npm run <script name> spawns a child process, the SHELL being used depends on NPM environment. Cм https://docs.npmjs.com/cli/run-script:
The actual shell your script is run within is platform dependent. By
default, on Unix-like systems it is the /bin/sh command, on Windows it
is the cmd.exe. The actual shell referred to by /bin/sh also depends
on the system. As of npm#5.1.0 you can customize the shell with the
script-shell configuration
See also https://github.com/npm/npm-lifecycle/blob/10c0c08fc25fea3c18c7c030d4618a401963355a/index.js#L293-L304
I wanted to run 'brew update' but run 'brew upgrade'.
After that, my tmux stop working on some functionalities.
For example, I cannot split windows. I have already tried using shortcut (Prefix-%), terminal command (tmux split-window), or tmux command (Prefix-:split-window). Sometimes the terminal divides the window for a fraction of time and then the new pane fades out. Sometimes nothing happens.
If tmux is detached, I can attach with tmux attach but some other commands are not working. For example, if I run tmux new-session -As "foo", it returns the string [exit] and if I inspect the return (echo $?), it returns 0.
I have already tried to run tmux without any configuration in case my tmux.conf have some problems. But when I run tmux -f /dev/null, it returns the string [exit] and if I inspect the return (echo $?), it returns 0.
The problem is that I am not sure if the problem is with tmux itself (it was upgraded to 3.2a - and I did not remember which version it was before) or if the problem is with another program or with the fact I am running with Mac M1 processor, that causes me problems in a bunch of situations.
I have already tried to downgrade tmux but there are not many materials on how to do that I the ones that I tried did not work. So I give up, especially because I was not sure if this would solve the problem.
In summary, I need some help at least to know how to best debug the problem.
Thanks!
I had the exact same problem and could fix it by just restarting my tmux session. Dettaching and reattaching is not enough.
I have as on single command "new" in my $HOME/.tmux.conf so I can call tmux attach as a command automatically using ssh. Recently (I believe since version 2.7) I am seeing a strange effect that if I use "tmux attach" and I do not have a session running a new session is started as expected (as I have the new command in my .tmux.conf) but the current working directory is "." if I use echo $PWD. If I use tmux without arguments to create a new session anyways I get a normal $PWD, in my case it is $HOME as I always call tmux right after logging in.
This wreaks havoc with a few shell scripts, for example the mvim script is not able to open any files in macvim any longer. If I use "cd $HOME" after using tmux attach for the first time when it created a new default session it works OK. Does anybody have any clue on how to fix that without issuing "cd $HOME"?
I just found that tmux version 2.8 fixes the problem.
I'm trying to wrap my head around this: on Windows, I use cmder (a wrapper around ConEmu) which improves on the bare cmd.exe experience (a lot) but can also host other shells like PowerShell or Git Bash. I'd like to go more "unix-y" but still well integrated with my Windows tools. Git Bash strikes the right balance for me: I can do things like rm -rf node_modules but still run my Windows commands fine.
It's easy to get Git Bash going inside cmder, however, I'd like to replace the shell with zhs, mainly to get the super-useful "up arrow respects the current prefix" feature (I write git, press the up arrow and only get suggestions on the recent Git commands).
The question is, who will handle the up arrow? Will it be ConEmu and do Windows-y stuff (cycling through all the commands) or will it fall down to zsh and the cycling will be implemented by it? How does this work?
Related: ConEmu: possible to change the up arrow behavior?
ConEmu's disclaimer states
ConEmu is not a shell, so it does not provide "shell features" like remote access, tab-completion, command history and others.
Only the shell itself knows when user types a command and only the shell may store executed commands history. Of course, only the shell may process Up/Down/Tab keys to "browse" stored history of commands.
cmder is a bundle of tools including clink, which integrates into cmd.exe and process cmd's prompt internally. So, in cmder by default Up/Down/Tab arrows are processed by clink.
More info is here: http://conemu.github.io/en/TabCompletion.html
I just started using Zsh lately for some of the integrated support in the shell prompt for my Git status etc.
When I type in:
ruby -v
to confirm the version of ruby I'm running, Zsh asks if I want to change the command to _ruby. Well after saying no at the prompt and the command completing as expected I continue to get the question at the prompt after confirming my command is correct.
I'm assuming there is a completion file or something of the sort.
Thanks
Update:
The shell is no longer trying to complete _ruby, it stopped responding after closing the shell a few times some how.
I tried to clean the file up several times but there is a "opts" variable that is 50 or more lines long and the lines are all ran together, some lines more than 150 characters. Maybe I could email an attachment to you if you still want to see it.
I sincerely apologize for the messy post.
This is command autocorrection, activated by the correct option. It has nothing to do with completion. You're seeing _ruby because zsh thinks there is no ruby command and it offers _ruby as the nearest existing match.
If you've just installed ruby, it's possible that zsh has memorized the list of available command earlier, and it won't always try to see if the command has appeared in between. In that case, run hash -rf. Future zsh sessions won't have this problem since the ruby command already existed when they started.
Sometimes, when you change your PATH, zsh forgets some hashed commands. The option hash_listall helps against this. As above, if you can force zsh to refresh its command cache with hash -rf.
You could make an alias:
alias ruby='nocorrect ruby'
It's what I did when zsh kept asking me if I meant .meteor when I typed meteor because auto-correct is still useful from time to time.
I find the autocorrect feature can get annoying at times. So I do in my ~/.zshrc,
DISABLE_CORRECTION="true"
I had the same problem even when the command is not installed.
I can solve it using the CORRECT_IGNORE variable in my .zshrc
# OPTs to enable
setopt HASH_LIST_ALL
setopt CORRECT
# Zsh variable to determine what to ignore,
# in this case everything starting with _ or .
CORRECT_IGNORE="[_|.]*"
I hope it helps to you or anyone with this issue
Sometime ago after an update, I got command auto-correction enabled which I don't want. If the same happened to you and you want to revert it, in the ~/.zshrc file you'll have make it:
# Uncomment the following line to enable command auto-correction.
ENABLE_CORRECTION="false"
or comment it as per bellow:
# Uncomment the following line to enable command auto-correction.
# ENABLE_CORRECTION="true"
Just a note, on my zsh (version 5.7.1 on macOS), the DISABLE_CORRECTION didn't work.
I saw in my .zshrc file the following two lines, which I then commented out
setopt CORRECT
setopt CORRECT_ALL
That did it for me.