Waiting and retrying

After sending input or starting a process, wait for the state your next step requires. Pane interaction covers waiting for screen text. This page covers arbitrary conditions and tmux’s named $wait-for signal channels.

Polling a condition¶

Polling checks a condition repeatedly until it succeeds or a deadline expires. Set a deadline and choose an interval that limits unnecessary tmux commands.

Helper: flibtmux::test::retry_until(within, condition)

Where it lives: crates/libtmux/src/test.rs, enabled with the test-support Cargo feature.

Examples¶

libtmux::test::retry_until(std::time::Duration::from_secs(5), async || {
    session.windows().await.map(|ws| ws.iter().any(|w| w.name() == "build")).unwrap_or(false)
})
.await?;

tmux’s own $wait-for channel¶

Use $tmux wait-for -S <channel> to signal and tmux wait-for <channel> to block until signalled. This avoids repeated screen captures when the command can announce its own completion:

mServer.signal_channel signals a channel. mServer.wait_for_channel waits with a timeout and returns a EChannelWait indicating whether it was signalled or timed out.

server.signal_channel("built").await?;
let outcome = server.wait_for_channel("built", std::time::Duration::from_secs(5)).await?;

tmux remembers a signal sent before a waiter starts. The next wait on that channel returns immediately, so completion is not lost when the command finishes first.

A raw wait-for client can exit zero when the server dies, as well as when the channel is signalled. Verify server liveness when a lost server must be treated as a failed task.

Use a channel name specific to the task. A remembered signal can otherwise satisfy an unrelated later wait.