Capture pane output

Edit this page on GitHub

The other half of Attach and send keys: reading what a pane printed, and — since tmux accepts a command before the shell running it has necessarily finished (see Sending keys) — waiting for the right moment to read rather than reading immediately or sleeping a guessed amount. Capturing output is the guide-level discussion of why each pattern below exists; this page is the sourced code behind it — see the table at the end for exactly which file each block came from and how it’s checked.

Read what’s on screenLink to section

            let lines = pane.capture().await?;
            for line in lines.iter().filter(|line| !line.as_bytes().is_empty()) {
                println!("  | {}", line.to_string_lossy());
            }

No checked .NET example calls the ordinary Pane.CaptureAsync by itself outside a wait — the README’s own read is the block under “Wait for text instead of guessing a delay” below, and the separate Psmux surface has its own CaptureAsync for that different transport (examples/LibTmux.Examples/Snippets/Psmux.cs).

Wait for text instead of guessing a delayLink to section

Python’s checked wait is wait_for, tmux’s own signal channel, rather than a helper that scrapes pane text for a pattern — no checked helper that waits on pane text was found in the source for this page.

Session.OpenNotifications streams what tmux does as it happens rather than polling — tmux pushes each change instead of a poll guessing how often to ask. tmuxtest.WaitForText (see Testing with libtmux) is the equivalent built specifically for tests.

// From crates/libtmux/examples/scratch.rs, the wait_for_text call — shown in full on Attach and send keys.
match pane.wait_for_text("hello", Duration::from_secs(5)).await? {
    PaneWait::Arrived => println!("  the pane printed it"),
    other => println!("  gave up: {other:?}"),
}

Rust’s wait_for_text looks before it sleeps, joins wrapped lines so a needle spanning a wrap still matches, and returns PaneWait::Dead rather than hanging forever if the pane’s process ends first.

Attaching a ControlClient is what makes tmux push %output at all — a client that never attaches only ever hears command replies.

TmuxWait.UntilAsync polls a read against a predicate rather than sleeping a fixed amount.

C++ has no checked snippet that waits on pane text. Server::wait_for(channel, timeout), in include/libtmux/server.hpp, uses tmux’s own wait-for signal instead of scraping output, and its doc comment explains why that is the safer choice when the command you are waiting on can be made to announce itself: “a server that dies under a waiter makes tmux exit zero, which is indistinguishable from being signalled … this reports that as a failure instead.”

waitForOutput takes patterns for both success and failure, so a process that fails fast is discovered immediately rather than by timing out.

Where this comes fromLink to section

Go, Rust, and Swift each reuse a file already shown in full on Attach and send keys: rather than dump the same file a second time, this page quotes just the relevant lines by hand, with a comment naming the source, and points back at the full listing there.