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

Read evar using os.getenv() in wezterm.lua doesn't work #6612

Closed
ckt114 opened this issue Jan 28, 2025 · 6 comments
Closed

Read evar using os.getenv() in wezterm.lua doesn't work #6612

ckt114 opened this issue Jan 28, 2025 · 6 comments
Labels
bug Something isn't working

Comments

@ckt114
Copy link

ckt114 commented Jan 28, 2025

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

macOS

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

N/A

WezTerm version

20240203-110809-5046fc22

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

I have to following code in ~/.config/wezterm/wezterm.lua

local use_tmux = os.getenv("WEZTERM_USE_TMUX") == "true"

return {
  ...
  enable_tab_bar = not use_tmux,
  ...
}

and I have the following line my my ~/.zshrc

export WEZTERM_USE_TMUX=true

but when WezTerm starts it doesn't work. Is it possible to read environment variable in wezterm.lua?

Thanks

To Reproduce

No response

Configuration

Provided in example.

Expected Behavior

Should be able to read evar from os.getenv("VAR")

Logs

No response

Anything else?

No response

@ckt114 ckt114 added the bug Something isn't working label Jan 28, 2025
@bew
Copy link
Contributor

bew commented Jan 29, 2025

The reason it doesn't work is because when the configuration is read, it can only read evars that were set before wezterm is started.
In your case zsh is actually started by wezterm after the configuration is loaded and the configuration cannot access the evars of a child process (by design on Linux/MacOS).

An alternative to what you're trying to do, could be to just hide the tab bar when there is only one tab
https://wezfurlong.org/wezterm/config/lua/config/hide_tab_bar_if_only_one_tab.html

@ckt114
Copy link
Author

ckt114 commented Jan 29, 2025

The enable_tab_bar was just an example. I just that use_tmux var as condition for leader key, keys, and key_table as well. Do you know of an alternative? Thanks.

@bew
Copy link
Contributor

bew commented Jan 30, 2025

I see, if you're using the wezterm's shell integration described here:
https://wezfurlong.org/wezterm/shell-integration.html#user-vars
You could then write a handler in your config to detect when WEZTERM_IN_TMUX is set, and change some state to get different behavior 🤔.

More stuff to read on how to pass data from pane to your config:
https://wezfurlong.org/wezterm/recipes/passing-data.html

@ckt114
Copy link
Author

ckt114 commented Jan 30, 2025

I read through the shell integration docs and added the below lines to my ~/.zshrc file but I don't see the WEZTERM_IN_TMUX evar like it mentioned in the doc when I'm inside tmux. I also added set -g allow-passthrough to my ~/.config/tmux/tmux.conf as well.

source $HOME/.config/wezterm/shell-int.sh
__wezterm_user_vars_precmd   # Added this anyways to see if it works but it doesn't work

@bew
Copy link
Contributor

bew commented Jan 30, 2025

It does not set an evar, but sets a user variable for the current wezterm pane.

Those can be detected in your config by registering a handler to react to a user var being set.
See: https://wezfurlong.org/wezterm/config/lua/window-events/user-var-changed.html

But you can also access the user variables of a pane with pane:get_user_vars():
https://wezfurlong.org/wezterm/config/lua/pane/get_user_vars.html

Make sure to read this section thoroughly:
https://wezfurlong.org/wezterm/recipes/passing-data.html#user-vars

@ckt114
Copy link
Author

ckt114 commented Jan 30, 2025

Awesome. Thanks.

@ckt114 ckt114 closed this as completed Jan 30, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants