Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WezTerm overwriting $SHELL variable #4168

Closed
LordMZTE opened this issue Aug 19, 2023 · 2 comments
Closed

WezTerm overwriting $SHELL variable #4168

LordMZTE opened this issue Aug 19, 2023 · 2 comments
Labels
bug Something isn't working

Comments

@LordMZTE
Copy link

What Operating System(s) are you seeing this problem on?

Linux X11

Which Wayland compositor or X11 Window manager(s) are you using?

i3

WezTerm version

wezterm 20230712-072601-f4abf8fd

Did you try the latest nightly build to see if the issue is better (or worse!) than your current version?

No, and I'll explain why below

Describe the bug

When the $SHELL variable is set in WezTerm's environment, WezTerm will unset it and populate it with the login shell obtained from /etc/passwd, clobbering the environment of the shell process running inside WezTerm.

This happens because this code deletes the variable, which causes cmdbuilder::get_shell to look up the login shell. This then ends up getting saved in $SHELL for processes running inside WezTerm.

While this behavior is explained by the fact that people often don't relog after updating their login shell, I believe that it not only makes no sense to work around user error, but also that it's rather uncommon for people to have $SHELL set in the environment WezTerm runs in. Those who do probably have a good reason for doing so, which WezTerm currently ignores. This situation is made worse by the fact that this is not fixable by adjusting WezTerm's config either, and thus the only way to currently work around this is to configure every shell which WezTerm might run to "undo" this.

I did not use a nightly build as the code causing this is still present on master.

To Reproduce

  1. Set SHELL to something other than your login shell.
  2. Start WezTerm.
  3. See that WezTerm will have set SHELL to your login shell.

Configuration

See here. This is not required as this can be reproduced without a config.

Expected Behavior

The $SHELL variable remains unchanged inside WezTerm.

Logs

Debug Overlay
wezterm version: 20230712-072601-f4abf8fd x86_64-unknown-linux-gnu
Window Environment: X11 i3
OpenGL: NVIDIA GeForce RTX 2080 SUPER/PCIe/SSE2 4.6.0 NVIDIA 535.98
Enter lua statements or expressions and hit Enter.
Press ESC or CTRL-D to exit

Anything else?

No response

@LordMZTE LordMZTE added the bug Something isn't working label Aug 19, 2023
wez added a commit that referenced this issue Aug 20, 2023
* Allow set_environment_variables to set the SHELL.
  Previously, we'd always set it to the shell from the password
  database.  Now we do that by default, but if set_environment_variables
  has been used, we'll preserve that value for the environment
  of the to-be-spawned process

* Clarify the docs:
  * Remove the confusing version dependent sections that started
    with old behavior and rewrite in terms of the behavior that
    has been true for the past year
  * I've heard from a few people that they tried to change COMSPEC
    on Windows and pain ensued.  Try to nudge them to read the
    next paragraph that tells them what they are actually supposed
    to change.

refs: #4098
refs: #4168
closes: #3816
refs: #3317
@wez
Copy link
Owner

wez commented Aug 20, 2023

This is intended behavior. The bug is that you can't override SHELL via https://wezfurlong.org/wezterm/config/lua/config/set_environment_variables.html, which has now been fixed in main.

@wez wez closed this as completed Aug 20, 2023
@github-actions
Copy link
Contributor

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Sep 20, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants