Re: [Help-bash] Why bash does not recoganize array type smartly?

[Dan Douglas]

On 3/16/16, Stephane Chazelas <address@hidden> wrote:
> 2016-03-16 14:22:41 +0000, Dan Douglas:
> [...]
>> An example problem I'm having right now that might be more easily
>> solved is lots of bash shells opened in tmux sessions, where If i log
>> in more than once and re-attach, there's no way to synchronize the
>> environment of all my running shells with the updated tmux session.
>> With dbus-glib support in bash I could potentially register a bash
>> function with dbus and call it from the new login session to update
>> the environment (without having to rely on sigusr traps).
> [...]
>
> Sounds like you could use some
> ~/.tmux/bash-sessions/${TMUX//\/_} files and a $PROMPT_COMMAND
> that sources them for that (assuming I understand what your
> saying).

That's basically what my current solution is. I heard zsh has a
pre-command variable that would be much better but I still need some
ugly hacks to make it work.

It's partly tmux's fault for managing the environment strangely. It
gives you a way to copy parts of the client's environment into tmux's
session environment (blowing away the existing environment) but no way
to access (or remember) the environment of all attached clients
directly.

I currently use an attach hook to update the global environment plus
some bindings that call shell functions for copy/pasting the X
selection. The tricky bit is executing bash with an empty environment,
passing in a function to get what the environment of a new login shell
would be plus the TMUX variable that gets wiped from the environment
when executing bash.

https://gist.github.com/ormaaj/221b95dc27133c0b9eaf

Anyway, the dbus thing would be an RPC mechanism. A directory filled
with fifos/files for every shell leaves much to be desired.