Terminal sessions

While DataMind Oda works on a task, it can open a terminal session: an interactive shell that Oda types into and reads as it works. A session is one of Oda's own shells, not the terminal in your side panel, which you type in yourself. This page covers what Oda can do in a session, what busy, idle and unknown mean, how signals reach the work running in a session, and how a session closes.

The commands Oda runs on your computer are a separate surface; Command environment and containment covers them. For the shell Oda keeps for those commands, see Persistent PowerShell shell.

Open a session and work in it

What the chat shows. When Oda opens a session, a row in the chat names it: started terminal session <id> (<name>) [type: <type>], with the session's id, its name and its type.
Input and reading. Oda types into the session and reads what comes back.
Size and type. A session is created with its size and its terminal type; programs inside see the type as their TERM setting.
Resize re-fits. Resizing the session re-fits the text; nothing running in the session is restarted or recreated.
After exit. Once the shell has exited, typing into the session or resizing it is refused, and the result says terminal process has exited.

How Oda watches a session

Oda watches whether a session is busy or idle, so it can tell quiet from working. The state is idle, busy or unknown, and each report carries a revision that moves on when what Oda sees changes.

Idle is never assumed. An incomplete observation is not reported as idle; when Oda cannot be sure, the answer is unknown.
Typing clears the reading. Input ends the evidence behind an earlier idle answer.
Quiet work still counts. Anything still running in the session keeps it busy; a job that has been stopped does too, even after its prompt returns, until that work is resumed or ended.
Where the watch works. It works only for the plain interactive bash (version 4.4 or newer) and zsh sessions Oda can observe. Other shells, commands started in custom ways, custom signal traps or prompt handlers, and Windows report unknown.

Send a signal

Oda can signal the work running in a session. The signal goes to the session's foreground process group: normally the command the shell is running right now.

The three signals. Interrupt, terminate and force (SIGINT, SIGTERM and SIGKILL).
On Windows. Only these three reach a session, and a request for suspend or hangup is refused. An interrupt on Windows arrives the way a Ctrl-C is typed, as keyboard input to the program.
On other systems. The wider set is available, suspend and hangup included.
A force kill at the shell itself is refused. To end a session, Oda closes it instead, which stops the shell and everything running in it.

How a session closes

The whole session stops. Closing ends the session and everything running in it: Oda stops the work in the session first, then the shell itself. It asks the processes to stop, and forces anything still running after a short grace period.
After a close, the result reads closed terminal session <id>.
Closing is safe to repeat. A second close while one is still finishing reads terminal session <id> was already closing and changes nothing.
A clean end is marked. A session whose shell ends with exit code 0 shows its result with a success tone.

Questions, answered

What do busy, idle and unknown mean?

Busy means Oda can see work running in the session. Idle means Oda can see the session sitting quietly with nothing else running in it, so the work it was doing appears to be finished. Unknown means Oda cannot observe the session clearly enough to say, and an unclear observation is never called idle.

Why is a session's activity unknown?

Oda reports idle only when it can observe the session clearly, and an incomplete observation is never passed off as idle. A shell other than the plain interactive bash or zsh sessions Oda can watch, a custom signal trap or prompt handler, and Windows all answer unknown.

Does idle mean the command has finished?

It means Oda can see nothing running in the session at that moment, so the work appears to be done. The reading is only as fresh as the moment it was taken: once Oda types into the session, the earlier answer no longer stands and the next report is taken fresh.

How are signals different on Windows?

On Windows, only interrupt, terminate and force reach a session, and a request for suspend or hangup is refused. An interrupt arrives the way a Ctrl-C is typed: as keyboard input to the program running in the session.

Does a signal stop the whole session or just the running command?

A signal goes to the session's foreground process group, which is normally the command the shell is running right now. The session stays open after the signal, ready for what comes next.

Why is input refused after a session's shell exits?

Once the shell has exited, the session is over, so typing into it or resizing it is refused, and the result says terminal process has exited. The attempt is refused rather than silently dropped.

What happens to the work running in a session when Oda closes it?

Closing stops the session and everything running in it. Oda stops what the session is running first, then the shell itself: it asks the processes to stop, and forces anything still running after a short grace period.

What happens when a session is closed twice?

Closing is safe to repeat. Once a session is already on its way out, a second close reads terminal session <id> was already closing and changes nothing; the close already in flight finishes on its own.