So IDK too much about multiple servers (I start a new one up after 10 windows so I can easily switch but nothing as complex as what you described). Wrt passing parameters to a remote shell though (as I do the reverse of what you describe) is just a declare -f && run it.
https://github.com/ag4ve/misc-scripts/blob/master/tmux-start.sh On Sep 28, 2017 4:49 PM, "Seth Milliken" <[email protected]> wrote: > I have a use case for comprehensive windowing environment orchestration > that appears to require more precise addressing of tmux clients than is > natively available in tmux. I am curious to get feedback on this scenario, > and whether there might be an approach to it I hadn't considered. Or feel > free to attempt to convince me I shouldn't be trying to do this crazy thing > at all. :-) > > Here is the scenario: > > On my local host, I have multiple terminal windows each with an ssh > session to the same remote host that is running a tmux server (all of these > tmux clients are connected to the same tmux server socket). I invoke a > keybinding on the local host that runs a custom window arrangement script; > this script directs the local host's window manager to arrange local > windows in a certain configuration and simultaneously uses ssh commands to > direct each of the remote host's tmux clients to switch to a particular > tmux session with a desired tmux window layout. > > The lines in the script that orchestrate the remote host's tmux > arrangement might look like these hypothetical examples: > > `ssh myserver 'tmux source-file -c desktop-writing /path/to/tmux/snippets/ > release-notes-draft-layout.tmux'` > `ssh myserver 'tmux source-file -c desktop-todo /path/to/tmux/snippets/ > development-checklist-layout.tmux'` > > But these hypothetical commands would require 'source-file' to take a > target client argument, and for tmux clients to have user-settable names a > la sessions. > > > Using a different socket for each client would allow me to reliably send > some commands to specific clients, but I'd prefer to keep all sessions in > the same server since I still want to easily switch between sessions when > I'm attaching from a much less capable mobile setup. > > Another approach (which I'm currently working on) is to try to script the > client creation so I can programmatically add the associated tmux client > tty to an external-to-tmux key-value store indexed by my own name for the > client. The orchestration script can later look up the needed tty by this > key, issue a `switch-client -c` targeting that tty, and rely on the > MRU-client-gets-subsequent-tmux-commands behavior to be able to send > additional commands to that particular client. This seems like it might be > a bit fragile, though. > > Any thoughts? > > -- > You received this message because you are subscribed to the Google Groups > "tmux-users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send an email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "tmux-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
