# Capturing output

Source: https://libtmux.org/en/java/latest/guides/capturing-output/

> Read pane output with an explicit completion condition.

[`Pane.capture`](<https://libtmux.org/en/java/latest/reference/io-github-libtmux-pane-pane-capture/>) returns visible pane contents as a list of lines. The complete
program compares a full line with its expected value and checks a monotonic
deadline. A `finally` block kills its private tmux server, while
try-with-resources closes the [`Server`](<https://libtmux.org/en/java/latest/reference/io-github-libtmux-server-server/>) handle.

## Run the complete program

[Capture pane output](https://libtmux.org/en/java/latest/examples/capture-pane-output/) includes the full
Java 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.

<a id="dont-poll-wait-for-the-text-instead"></a>

## 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](https://libtmux.org/en/java/latest/guides/sending-keys/) explains why returning from the
input call is not a completion signal.

<a id="when-the-pane-can-announce-itself-wait-for-not-scraping"></a>

## 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](https://libtmux.org/en/java/latest/topics/waiting-and-retry/) documents this port's waiting
APIs and failure handling.