Automation for doing stuff in multiple windows in tmux

Tmux is terminal multiplexer. Kinda like old screen, but with much more functionality.

When I work on my servers, it's pretty common that I have to do the same things to multiple servers. To make my life easier I start tmux, and in there start many “windows", each related to work on single server.

I name the windows in a way that let's me quickly find them, without false positives.

For example, if I'd have to upgrade servers db1..db5 then I'd create windows “up-db1" .. “up-db5", and each window would work on single server.

This is already scriptable – let's assume I'd want to show uptime in all of the windows, I can:

tmux lsw -F '#W' | grep -E '^up-db[0-9]+$' | xargs -r -d$'\n' -I% tmux send-keys -t % uptime Enter

But this gets tedious fast.

So I wrote tmux_send_to_many script.

Thanks to it, I can rewrite the pipeline above into simpler:

tmux_send_to_many '^up-db[0-9]+$' uptime Enter

It has options to debug, list panes/windows that would get the keys, or even to send keys to different sessions.

Full help:

=$ tmux_send_to_many -h
    /home/depesz/bin/tmux_send_to_many [-a] [-l] [-v] PANE_MATCHER LIST OF STRINGS

    -a : Enables matching across all sessions, not only current.
    -l : List all matching panes and exit, don't send any keys.
    -v : Print verbose information while working.

    PANE_MATCHER    : Regular expression (compatible with egrep), that will be
                      used to select panes that should be processed.  Without
                      -a, panes are listed only from current session, and have
                      With -a, panes are listed from all sessions, and have
    LIST OF STRINGS : What should be sent to all selected panes.

If you're interested, it's licensed under 3 clause BSD license.

2 thoughts on “Automation for doing stuff in multiple windows in tmux”

  1. tmux is truly a hero application.

    ~2 years ago I was tasked to migrate a MySQL database to PgSQL. I had a few months prepping the procedure and I would have loved to use pgloader but the more I increased the concurrency, the more likely it did fail. We’re talking about a procedure which already takes hours by itself only for pgloader to fail at unknown points (really unfortunate).

    Long story short, I figured I use only pgloader only for data pumping but constraint/indices where covered with custom SQL scripts parallelized via … tmux!

    Automatically spawning them, coordinated via a shell script (with inter-dependencies, i.e. waiting for certain tmux windows to finish using tmux signaling and locks), I was able to successfully perform the migration.

    Looking back it reads like a miracle this worked, but everything was fine-tuned and tested over a few months.

    Still use it for day to day work, awesome successor to screen.

Comments are closed.