mcp.exec.WaitOutcome
Rust
- Python Unavailable
- Ruby Unavailable
- Lua Unavailable
- TypeScript Unavailable
- Rust
- Go Unavailable
- Java Unavailable
- .NET Unavailable
- C++ Unavailable
- Swift Unavailable
-
How a wait for text finished.
Members
-
A wanted pattern was already in the pane's output before this began watching, on a row above the one still being typed into, and is not a line this server itself submitted moments earlier.
A wait only sees what a pane writes after it starts, so this is never folded into
Self::Matched: the same pattern printed moments earlier -- an earlier command's own output, say -- can already be sitting there, and a caller that treated that as a fresh match would act on something that happened before this call, not because of it. A line this server typed and submitted withsend_keysis discounted rather than reported here or asSelf::Matched, for a short time after it was submitted.
-
A wanted pattern's only occurrence is the row still being typed into: text this server (or a person sharing the pane) sent and has not submitted, not anything that has run.
Submit it, then wait again: the next wait sees the command's own output on a row above a new one still being typed into, which is
Self::PresentAtEntryorSelf::Matcheddepending on when it arrived, never this -- and never the submitted line's own echo, which stays discounted for a short time after.
-
A pattern matched, in output that arrived after the wait attached.
-
A stop pattern matched, so the wait ended early.
-
The time the caller allowed ran out.
-
The pane stopped writing for good.
-
The client withdrew the request while the wait was still running.