-
-
Notifications
You must be signed in to change notification settings - Fork 801
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
Comments
* 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
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 |
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. |
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
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
The text was updated successfully, but these errors were encountered: