Capturing output
Pane.Capture takes a tmux.CapturePaneRequest. Use Start and End to choose
a range; tmux.CaptureBoundary reaches the corresponding history or screen
boundary. The complete program reads the visible screen, compares full lines
and stops when its context expires.
Run the complete program¶
Capture pane output includes the full
Go program, all imports, project files and a run command. The program
matches libtmux capture ready as a complete line, so the echoed command cannot
satisfy the check. It creates and cleans up its own tmux server.
Visible pane vs. scrollback¶
A capture reads terminal state. Lines that have scrolled beyond retained history are unavailable, and repeated captures can miss intermediate output. Choose the range your task needs and use a stream or completion signal when every output event matters.
Wait for the expected text¶
Use a deadline and a specific output predicate. The example’s short polling pause limits work between checks; it is the observed line that determines completion. Sending keys explains why returning from the input call is not a completion signal.
Wait for a completion signal¶
A program can also signal a dedicated tmux channel. Use the same server endpoint for the sender and waiter and a new channel name per task. Waiting and retrying documents this port’s waiting APIs and failure handling.