Re: callback?

[Oliver Kiddle <opk@xxxxxxx>]

Matt Zagrabelny wrote:
>
> I am using tmux with zsh.
>
> I use ssh agent forwarding and I ssh to a remote system that is running tmux. I
> then detach from that terminal and my SSH_AUTH_SOCK environment variable
> becomes "stale".
>
> I would like to have zsh execute something to refresh the SSH_AUTH_SOCK
> environment variable when I "tmux attach" to the aforementioned detached tmux
> session.
>
> Does anyone know of a way to register a callback or something for zsh so when a
> particular command gets run (in my case, tmux attach) my zsh environment
> variable can get updated?

When "tmux attach" is run, it'll be run by a different instance of zsh
to those within the tmux session. It is tmux's child processes that need
to receive a callback but I don't think there's any way for tmux to send
callbacks. Nor can I think of a particularly sane way that could be
implemented in tmux.

tmux does provide access to the environment for the current session so
you can run something like the following to import a variable into the
running zsh:

  eval $(tmux showenv -s SSH_AUTH_SOCK)

You might even set an alias, e.g:

  alias fixssh='eval $(tmux showenv -s)'

In the absence of a direct tmux callback, the easiest may be to detect a
stale ssh socket in an existing zsh callback function such as preexec().
There appears to be a TMUX environment variable which can be used to
detect a shell that is a a child of a tmux process. So something like
the following may work well enough:

if (( $+TMUX )); then
  tmuxrefreshenv() {
    [[ -r $SSH_AUTH_SOCK ]] || eval $(tmux showenv -s)
  }
  add-zsh-hook preexec tmuxrefreshenv
fi

For something more direct than preexec, you could also try trapping
SIGWINCH. tmux will send this to child processes if the pane is resized
as a result of tmux attach - which is fairly likely. But it is also sent
when the pane is resized for other reasons and may not be sent if you're
consistent in your window sizing.

Any approach is going to have limitations - it won't pass through
subsequent layers of child processes using su, ssh and similar.

Another quite different approach would be to use the IdentityAgent
option in ~/.ssh/config to ensure a consistent path to the agent socket
so that the value remains valid instead of becoming stale.

Oliver