Perplexed; environment variables not recognized

[gwww]

I'm building a key mapping to edit my config file in nvim.

The environment variables never are recognized and vi (the third fallback) is always taken. I'm using zsh on MacOS. The environment variables are set in .zshenv. I can see in ps a /usr/local/bin/zsh -l from when I started wezterm. I can also see in ps a vi /Users/glenn/.config/wezterm/wezterm.lua when I invoke the action below.

Code:

wezterm.on(
  "edit_wezterm_config",
  function(window, pane)
    local dir = "/Users/glenn/.config/wezterm"
    local editor = os.getenv("VISUAL") or os.getenv("EDITOR") or "vi"
    window:perform_action(wezterm.action {SpawnCommandInNewTab =
      {cwd=dir, args={editor, dir.."/wezterm.lua"}}}, pane)
  end
)

The rest works fine, just the os.getenvs don't work.

[wez]

Usually, Finder is what launches WezTerm.app on macOS. Your shell isn't involved in that process, so those environment variables likely aren't set on macOS.

The easiest thing to do is hardcode you preferred editor in wezterm.lua, but if you really want your shell involved there, you can probably do something like:

   args={
          os.getenv("SHELL"),
          "-c",
          "exec $VISUAL \"" .. wezterm.config_dir .. "/wezterm.lua\""
    }

[wez]

(See also: https://wezfurlong.org/wezterm/config/lua/wezterm/config_dir.html)

[gwww]

Thank you! Thank you! Except it didn't quite work. wezterm.config_dir returns the name of the config file, not the directory. Easy enough to fix my script.

Question then is should wezterm.config_dir return the name of the directory. I think so, at least based on its name. Perhaps there's two variables. wezterm.config_dir returns the directory and wezterm.config_path returns the full path to the name of the config file. Breaking change... but alpha/beta and all ;)

[wez]

doh, yeah, it should just be the dir. I think adding wezterm.config_path is good. FWIW, wezterm also exports WEZTERM_CONFIG_FILE and WEZTERM_CONFIG_DIR to the environment; those hold the name of loaded config file and directory respectively.

[wez]

b63a949 fixes this

[bugabinga]

I had a similar but different issue on Linux when trying to start the mux server via systemd.

In case someone else has a similar issue:

If you are starting wezterm-mux-server with the systemd user instance keep in mind that it does NOT inherit the environment variables from your session.
This is not an issue with wezterm but rather explicit design by systemd.
A quick'n'dirty workaround for me was to wrap the wezterm-mux-server command with bash like so:

[Unit]
Description=Wezterm Multiplexing Server

[Service]
# start with system shell as parent in order to inherit environment variables
ExecStart=/bin/bash -c /usr/bin/wezterm-mux-server
Restart=on-failure

[Install]
WantedBy=default.target

This only works for you if your distro has configured bash to source environment variables from some profile.

Update: Turns out I was very wrong!

The "fix" only happened to work because I kept restarting the service via systemctl --user restart wezterm, which then had an updated environment.
I am not sure how, but it seemingly is the case that gnome-session.target somehow inherits the environment.
The updated service looks like so

[Unit]
Description=Wezterm Multiplexing Server
After=gnome-session.target

[Service]
ExecStart=/usr/bin/wezterm-mux-server
Restart=on-failure

[Install]
WantedBy=gnome-session.target