Capturing output

Server.capture reads pane lines. The complete program compares a whole line, bounds the wait and reports cleanup errors. For repeated reads of changing output, the streaming APIs can track output beyond one screen snapshot; consult this version’s API reference for their lifetime and completion rules.

Run the complete program¶

Capture pane output includes the full Swift 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.