SHELL environment variable is set incorrectly

[tomjaguarpaw]

In my WSL I have my shell set (using chsh) to zsh. When I launch wsltty I do indeed get a zsh shell, but the SHELL environment variable is set to /bin/bash. This did not happen under the default Windows terminal. Using the default Windows terminal the SHELL environment variable was set correctly to /bin/zsh. Do you have any idea why this is happening? I wondered if #95 was related but I was not sure.

[mintty]

None of mintty, wslbridge, or the profile scripts on the system where I reproduced this (kali-linux) set the SHELL variable. Somebody with detailed knowledge of what happens under the hood when logging in to Linux may be needed to give us a clue. @rprichard perhaps?

[kailiu42]

I'm running openSUSE Tumbleweed WSL and I did notice this issue too.

[nhoad]

I'm on ArchWSL, same issue here.

[j-c-m]

rprichard/wslbridge#37

[mintty]

That patch is based on a rather old commit of wslbridge and I do not see right away how to apply it to the current version. It would be good to consolidate this first, then convince rprichard to accept the patch, and then it can be integrated with wsltty. Provided it works, of course.

[j-c-m]

Is that the wrong repo for wslbridge? I don't see any commits that would conflict with the patch -- or really any significant ongoing work at all.

The patch works, when setting up a login session and changing the shell it is correct to set the SHELL variable. For reference see linux login.c:

https://github.com/karelzak/util-linux/blob/d55db6724ce938ec7d5e6d4d3ed11379ade33266/login-utils/login.c#L1024

[mintty]

The repo is the right one.
Why don't you follow the suggestion in my previous comment?
You've based your patch on an outdated commit of wslbridge, if you rebase it to the current version, it will be easy to apply and test it. That might get it accepted in wslbridge or if it isn't, it could be applied when building wsltty. It's your turn.

[j-c-m]

The patch would cleanly apply to the master branch of wslbridge despite being 1 unrelated commit behind.

Regardless, I have rebased so it is now 0 commits behind, and also built a wslbrigdge-backend binary including the patch for any testing, anyone wishes to do.

https://github.com/j-c-m/wslbridge/releases/tag/0.2.5-dev-shellEnv

[mintty]

Well, your referred comment says

An update for 34ec0e4 / #17 to also set the SHELL environment variable.

which commit is dated 16 Nov 2017, maybe the backend hasn't changed so much since then... I'll check out again.

[j-c-m]

I understand the confusion now, that commit was referenced for the concept. The actual update I made was against the newest master at the time.

[thetrompf]

I just created a shortcut with the following command line:

%LOCALAPPDATA%\wsltty\bin\mintty.exe --configdir="%APPDATA%\wsltty" -~ -e %LOCALAPPDATA%\wsltty\bin\wslbridge.exe -t -l -eSHELL=/bin/zsh -eSHLVL=0 -C~

[mintty]

Thanks for the note. This is not a generic solution, however, and it could be accomplished as well within the WSL startup scripts. Maybe even better there as you would be able to determine the actual shell being used and set that into SHELL.

[thetrompf]

I am well aware, it was meant as a workaround, until a generic solution is found.

[sskeirik]

I recently ran into this issue as well. As an alternative solution to the complex mintty invocation shown above, I seem to be able to just add a:

[ -z "$ZSH_VERSION" ] || export SHELL="/bin/zsh"

snippet into my .zshrc to correct this issue. As far as I can tell, at least on my current WSL setup, there is no need for SHELL to be set correctly in the /etc system-wide scripts that are usually run first.

EDIT: Obviously, this only works for zsh and will need to be customized for any other shell, e.g. apparently fish exports a version variable.

[ckuai]

I recently ran into this issue as well. As an alternative solution to the complex mintty invocation shown above, I seem to be able to just add a:

[ -z "$ZSH_VERSION" ] || export SHELL="/bin/zsh"

Midnight commander also due to this issue can't use shell.... it turns out also due to the shell variable is not set to shell as in /etc/passwd but default to /bin/bash. Both default WSL1 terminal and the new Windows terminal preview do not have this issue.

setting [ -z "$ZSH_VERSION" ] || export SHELL="/bin/zsh" in .zshrc helps.

[mintty]

@Biswa96, would wslbridge2/hvpty handle this better?

[j-c-m]

rprichard/wslbridge#37

[Biswa96]

For my wslbridge2 repo, as I told before, $SHELL is handled by /init and those backends fork from them. So, backends don't interfere with it. Can you provide any case where $SHELL is shown incorrectly?

[j-c-m]

Are there plans to switch to @Biswa96 wslbridge2? It seems to fix this issue (and others) and the original wslbridge appears abandoned.

[mintty]

Yes, mintty 3.0.3 is in preparation and wsltty release shall follow it.

[mintty]

Released 3.0.5 with new gateway.