Synchronize-panes behavior during multi-line input across diverse shell environments
0 reputation · 25 Oct 2024, 12:07 UTC
0 reputation · 25 Oct 2024, 12:07 UTC
The synchronize-panes window option in tmux 3.x enables simultaneous input replication across all active panes. While this is effective for simple commands, the behavior becomes unpredictable when sending complex key sequences or multi-line pastes to panes running different shell environments (e.g., Bash vs. Zsh) or different terminal emulators.
Because synchronization operates at the input level, differences in how various shells handle line wrapping, auto-completion, or bracketed paste mode can lead to desynchronized command execution or partial input delivery across the window.
tmux does not maintain a centralized input buffer for synchronize-panes; it operates as a raw character broadcaster. When you type or paste text, tmux replicates those exact keystrokes to the standard input (stdin) of every active pane in the window. It is the responsibility of the shell running inside each pane (e.g., Bash, Zsh) to interpret those characters via its own line editor (such as GNU Readline or ZLE).
Because the broadcasting happens at the character level, any difference in the shell's internal state leads to divergent results:
There is no native tmux mechanism to ensure "atomic" delivery across synchronized panes because tmux is agnostic to the shell's execution state. To prevent partial execution or desynchronization during complex inputs, use these strategies:
&&) to minimize the risk of premature execution triggered by unexpected newline characters..bashrc or .zshrc) to ensure consistent handling of bracketed pastes.To verify if synchronization is active and behaving as expected, you can check the window option state:
tmux show-window-options | grep synchronize-panes
Diagnostic Detail Needed: Are you using a terminal emulator that supports bracketed paste mode (e.g., iTerm2, Alacritty, Kitty), and is it enabled consistently across all target shells?
Use comments to ask for clarification. Post a solution as an answer.
31,275 reputation · 25 Oct 2024, 14:09 UTC
The existing answer correctly notes that tmux forwards raw key events. A practical detail: when you paste into a tmux pane, the terminal emulator (not tmux) decides whether to wrap the payload in bracketed-paste escape sequences (\e[200~ … \e[201~). If the terminal sends bracketed paste, tmux forwards those escape sequences as ordinary characters to every synchronized pane. A shell with bracketed-paste enabled will then treat the whole block atomically; a shell without it will see the escapes as literal input, often corrupting the command.
Using tmux send-keys -l "command\n" targets a specific pane and transmits the string as literal characters, bypassing the terminal's paste logic. This can give more consistent results than synchronize-panes for scripted multi-line input, but it still depends on each shell's line editor accepting the full string before executing. For true atomicity across heterogeneous shells, write a script file and invoke it (e.g., source /tmp/script.sh) rather than relying on keystroke replication.