Control an interactive terminal

Two controls travel with a cmdop connect session: a keyboard interrupt reaches the program running on the target, and resizing your window resizes the remote one so full-screen programs redraw correctly. Everything else — job control, suspend and resume, what a program does when its terminal goes away — belongs to the target’s own shell and operating system, and Cmdop does not change it.

An interactive cmdop connect session behaves like a terminal, not like a one-way log. Two controls travel with the session:

• Interrupt — a keyboard interrupt reaches the program running on the target, the same way it would in a local terminal.
• Resize — resizing your terminal window resizes the remote one, so full-screen programs redraw at the right size.

Everything beyond that belongs to the target’s shell and operating system. Job control (background jobs, suspend and resume, process groups) behaves the way that shell behaves on that platform, and Cmdop does not change it. Test a signal-heavy workflow on the target platform before depending on its exact behavior.

End a session cleanly

Use the running program’s own exit command, then leave the session. That gives the program a chance to flush its work and return an exit status. Ending the session is not a substitute for stopping a long-running job: what a program does when its terminal goes away is the program’s own behavior.

Prefer a bounded command for automation

If nothing needs to be typed, do not drive an interactive terminal from a script. Use a one-shot command with an explicit deadline instead:

cmdop connect exec <machine> --timeout 60 -- <command>

--timeout is in seconds. This path is scoped to this host — see Run a one-shot command.

After an unexpected disconnect

Verify the state of the target before running the same state-changing command again. A disconnected client does not mean the command stopped.

cmdop connect exec <machine> -- <read-only check>

Common questions

Does Ctrl-C reach the remote program?

Yes. A keyboard interrupt in an interactive cmdop connect session reaches the program running on the target, the same way it would in a local terminal.

Does disconnecting stop the command?

Not necessarily. What happens when the terminal goes away belongs to the target program and shell. After a disconnect, inspect target state before retrying a state-changing command.

Should automation drive an interactive terminal?

No. If nothing needs to be typed, use cmdop connect exec with an explicit timeout instead of scripting an interactive terminal.