-
Establish the concept of a controlling terminal, that receives signals like Ctrl-C or Ctrl-Z from devices. This would also enable job control in the shell - that at this point can only wait for a child to end, or send it in the background altogether.
-
In addition, an (optional) terminal process will be established that allows windowing of shells - similar to Linux tmux as an example.
-
Establish a standard way of controlling the terminal, like moving cursor, defining sub-windows, …
1) STDCIN
-
per process, inherited from parent
-
DUP can change it, to be used in
-
TTY command to switch to another console
-> DONE
2) TTY handling (Streams)
-
Streams get a Controlling Task, inherited from parent
-
If a task sends a signal to a stream, the Controlling Task receives the signal
-
If a task wants to read the stream, but is not the Controlling Task, the read blocks.
-> DONE (except for 3. Blocking on read, which will be done in the new buffer/channel code))
2) TTY handling (Devices) Devices get an optional "line discipline". if set:
-
if Ctrl-C → signal (all) PGRP tasks SIGTERM
-
if Ctrl-D → EOF
-> DONE for the console. Other devices (like serials) need to wait until FSDEV and devices can process file open options
3) Job Control
-
On PUTC, if Ctrl-Z → SIGSTP to Controlling Task, send SIGCHLD to parent
-
Shell manages jobs (PGRP), e.g SIGCONT to children on fg/bg
-> DONE
4) Terminal server
This implements a terminal sharing task that works similar to e.g. tmux or screen on Linux/Unix machines. It requires a defined protocol between shell and terminal, that may be defined/enabled by an environment variable. (See 5. in below).
5) An API similar to curses so that programs have a standardized way of moving the cursor, defining sub-windows etc.
-
A new "term.a65" source code library implementing this API
-
An improved console (and associated stream protocol) that is more flexible, like defining sub-windows, returning screen geo on request etc.