DataMind Oda works in a terminal session through six tools: open, send, read, signal, close and list. This page is the reference for what each tool takes, what it returns and how its results are bounded.
How a session lives between calls, and what a wait or a refusal means, is on Terminal sessions. For the same calls written for the reader, see Terminal tools.
terminal_open starts a session of a type and returns its id, its type, its process id when the shell has one, its status, and a short startup message. The result reads started terminal session <label> [type: <type>], followed by that message or (no startup output).terminal_send writes text into a named session and waits for it to settle. By default the text ends with Enter; set submit false for control characters or incomplete input in an interactive program. With run_in_background the send starts a job instead and renders started background job <jobId> (see Sends in the background). A send stopped before it settles reports terminal send aborted.terminal_read returns the output the session kept, in pages: the read starts at the beginning and returns up to 500 lines by default, and a later read can start further in. A read with nothing kept returns (no retained output).terminal_signal delivers one of SIGINT, SIGTERM, SIGKILL, SIGTSTP or SIGHUP to what is running in the session and renders delivered <signal> to foreground process group <id>. A SIGKILL aimed at the shell itself is refused; close the session instead.terminal_close ends the session, its shell and everything running under it. Closing is safe to repeat: the result reads closed terminal session <id>, or terminal session <id> was already closing.terminal_list returns one line per session Oda holds: the id, the name in parentheses when set, the type in brackets, the status, and the process id when there is one, for example pty-1 [shell] running. With none held, it returns (no terminal sessions).type opens a session of that type; the type the app ships is shell.name is optional, a display name such as main or gdb, unique per chat.submit on a send defaults to true, so the text ends with Enter; false writes the text alone.offset and count on a read default to 0 and 500; the start must be a whole number not below zero, and the count must be a whole number of at least one.signal takes the five signals above.run_in_background on a send runs it as a job instead of waiting.Every result is text. A result longer than the size ceiling is cut at a character boundary and marked [output truncated]; the earlier part is kept.
| Marker | What it means |
|---|---|
(no startup output) | The session started with nothing to show yet. |
(no new output) | The send settled with nothing new; output you already read is not repeated. |
[wait: <reason>] | Why the wait ended; the four reasons are explained on Terminal sessions. |
[session: running] | The session was still open after the wait. |
[session: exited code=<code> signal=<signal>] | The shell ended during the wait; the note carries its exit code, the signal that ended it, or null where there is none. |
[output truncated] | The result was cut to fit the ceiling; the earlier part is kept. |
(no retained output) | A read found nothing kept. |
[lines: <first>-<last> of <total>] | Which lines of the kept output a read returned, and how many lines are kept in all. |
(no terminal sessions) | The list found no sessions Oda holds. |
run_in_background, the send runs as a job while the chat continues, and the start renders started background job <jobId>. The job is labelled with the session's id and the text sent.killed.run_in_background is not offered on the tool and a call that asks for it anyway is refused; a build without background job support refuses background sends the same way.Open terminal ., Read terminal ., Signal terminal ., Close terminal . and List terminal sessions.Send to terminal ..Background sending is on by default. Where the app is configured to turn it off, run_in_background is not offered on the send tool, and a call that asks for it anyway is refused. A build without background job support refuses background sends the same way.
256 KiB (262,144 bytes) by default. The smallest value the app accepts is 64 bytes. A result over the ceiling is cut at a character boundary and marked [output truncated], keeping the earlier part.
Set submit to false on the send. The text is then written alone, which is what control characters and incomplete input in an interactive program need; by default the text ends with Enter.
delivered <signal> to foreground process group <id> mean?It reports where the signal landed: signals go to what is running in the session, and the note names that process group and its id.
The job's reader binds when the send starts, so a read taken before that comes back empty rather than failing. Once the send is under way, each read continues from where the previous one stopped, so nothing is shown twice. See Background runs and jobs.
It is refused: every terminal call needs an initiating chat to belong to, and nothing runs without one.
A foreground send appears as a terminal card; the other calls appear as generic tool cards titled Open terminal ., Read terminal ., Signal terminal ., Close terminal . and List terminal sessions. A background send is titled Send to terminal ..
Yes. A result stays in the chat's history like any other tool result until the chat compacts; see Chat compaction.
With terminal_list, which returns one line per session: the id, the name in parentheses when set, the type in brackets, the status, and the process id when there is one. With none held, it returns (no terminal sessions).