Preserve environment variable when attaching to existing session

[blurgyy]

trafficstars

Currently the environment variables in shells opened in zellij are inherited from the session that starts the zellij server. It would be great to have the newly opened shells inherit the environment of the currently attached session. This is useful for, e.g., indicating current session is a SSH session via shell prompts.

[raphCode]

As far as I understand, you have a shell with, say, NEW_ENV="hello" set. You then attach to a pre-existing zellij session and expect zellij to apply that environment variable to every new pane you open from now on through this client?

That would probably be a bit confusing because you have to remember which panes have which environment as old panes already open still have the original server environment?

Can you elaborate on the use case?

[blurgyy]

Hi @raphCode, thanks for the reply.

As far as I understand, you have a shell with, say, NEW_ENV="hello" set. You then attach to a pre-existing zellij session and expect zellij to apply that environment variable to every pane you open from now on through this client?

~~No, I'm aware of that expecting zellij to change an existing shell's environments is indeed confusing, and that's not what I would expect, either.~~

Edit(I misunderstood the above question): Yes, I am requesting zellij to apply/merge the environments of the client to newly created panes/tabs ever since I attach this client to an existing zellij session.

Can you elaborate on the use case?

The specific use case is: when I open a new pane/tab, I would like to be able to tell if I am in an SSH connection or not, by examining the shell environment in new pane/tab. This is the behaviour of TMUX and it would be great if zellij can make this configurable (I don't know a way to make this configurable in TMUX, afaik this is a forced behaviour in TMUX).

To explain this, here is a screenshot of how TMUX (with completely default configuration) handles this:

^{where the 0-th pane (left) is opened locally, and the 1-st pane (right) is openned from an SSH connection.}

Note how the shell prompts in the two panes differ where the prompt in the 1-st pane (right) shows my username and my machine's hostname since it's opened from within an SSH connection so the shell inherits the SSH connection's environment variables.

I hope this makes it clearer.

[a-kenji]

How is your shell configured in tmux @blurgyy?

[blurgyy]

Hi @a-kenji,

How is your shell configured in tmux @blurgyy?

If you are asking about the shell prompt, it is managed by starship, which is configured to show my username if any of SSH_TTY, SSH_CONNECTION or SSH_CLIENT is set, and to show the machine's hostname if SSH_CONNECTION is set:

[a-kenji]

Hi @blurgyy, I will rephrase my question: Did you configure your shell in tmux? (through default-shell)

[blurgyy]

No, I did not configure my shell in tmux in the first screenshot.

The first screenshot was taken after I deleted my ~/.config/tmux/tmux.conf, and I just checked there is no other tmux configuration enabled (I don't have a ~/.tmux.conf).

[a-kenji]

@blurgyy, Thank you! That means that your shell is running as a login shell, maybe that could explain the behaviour? I am not to sure if tmux is actually sharing all the environment variables with every window.

Do you see the same behaviour when setting the shell as an interactive shell in tmux?

[blurgyy]

Hi @a-kenji, thank you for your reply!

Do you see the same behaviour when setting the shell as an interactive shell in tmux?

Yes, I think so:

I followed https://wiki.archlinux.org/title/Tmux#Start_a_non-login_shell to launch a non-login shell with tmux, does a "non-login shell" here mean an "interactive shell"?

---

Some extra information:

• The tmux.conf in use:

set -g default-command "${SHELL}"

• The fish script I used to launch and attach to an existing tmux session:

    set tsess "main"
    set default_wname "default"
    set wname (date '+%b-%d,%H-%M-%S')

    if not tmux has-session -t $tsess 2>/dev/null
      # If session '$tsess' does not exist, create first
      tmux start-server
      tmux select-window -t $tsess:0 \; \
        rename-window $default_wname
    end

    exec tmux new-session -t $tsess \; \
      new-window -n $wname \; \
      select-window -t $wname

[a-kenji]

@blurgyy, Thank you for checking! In that case it seems that tmux is indeed doing something special with the environment variables. This might warrant an option to include in zellij.

[blurgyy]

Cool, thanks for considering this!

[raphCode]

Thanks for the detail! If I understand correctly, this is your setup:

┌─────────────────────┐
│                     │       ┌───────────┐
│ ┌─────┐  ┌───────┐  │  ssh  │           │
│ │local├─►│ zellij│◄─┼───────┤ machine B │
│ │term │  └───────┘  │       │           │
│ └─────┘             │       └───────────┘
│      machine A      │
└─────────────────────┘

And you want zellij to pick up the environment from attached clients and apply it to newly opened panes.

I tested this, and indeed tmux does it, but only for some variables: https://github.com/tmux/tmux/blob/06869ff22fa9891c9633ce3e3efa77cac758b520/options-table.c#L746-L754

I still don't think this is a good idea because panes have different envs depending on who opened them and not based on who is using them. Also this leads to stale environments after the ssh connection closes and the clients go away.

But, if tmux does it, we might too...

[dsully]

+1 - I just ran into this issue where I have Neovim's clipboard setup to use OSC52 via SSH but pbcopy/pbpaste otherwise.

If my zellij session was started in a local terminal, then I SSH into it, Neovim still think's I'm local.