== The well behaved Unix program and job control signals

[[The TTY demystified
http://www.linusakesson.net/programming/tty/index.php]] (which I've
commented on [[before TTYLineDisciplineWhy]]) has some things to say
about the SIGTT* job control signals. In the process it says something
about how they are and should be handled that I think is dangerously
misleading.

Specifically, contrary to what [[The TTY demystified]] says, you
shouldn't assume that the shell saves and restores TTY modes for
you when your program is suspended and restored. A well behaved
Unix program that changes the TTY modes will remember and restore
the original modes when it gets _SIGTTIN_ or _SIGTTOU_, and then
re-set them to what it needs when it gets _SIGCONT_. Note that a
well behaved program may need to do much more than just save and
restore TTY modes; one of the reasons that programs get sent the
SIGTT* signals (instead of just being abruptly suspended) is so
that they can do things like reset the terminal state away from
whatever peculiar colours and other settings they've placed it into.

(This is where [[the alternate screen plague AlternateScreenPlague]]
kicks in.)

These days I think that basically all surviving shells (at least ones
with job control) do save and restore TTY modes for you, because sadly
this is basic self defense on part of the shell. However, they generally
don't reset the terminal state (partly because they often have no idea
what state you've put it into).

(This has implications for how your program should handle _SIGTTIN_, but
that'll take another entry.)

The article also asks (after discussing ^S/^Q flow control):
> I don't know why the designers of UNIX had to go all the way to invent
> _SIGTTOU_ and _SIGTTIN_ instead of relying on blocking I/O, but my
> best guess is that the TTY driver, being in charge of job control, was
> designed to monitor and manipulate whole jobs; never the individual
> processes within them.

The straightforward answer is that the SIGTT* signals are designed to
give your program a chance to react to being suspended. That's why
you can catch them at all, unlike _SIGSTOP_. If the TTY driver simply
blocked your process from doing further TTY IO (or just sent you a
_SIGSTOP_), your program couldn't clean up any special state it had set
and doing this would be entirely on the shoulders of the shell (which
cannot do it as well as your program can in many situations).

=== Sidebar: why the shell has trouble restoring the terminal state

At one level and in theory, restoring the terminal state is simple;
the shell can just send the terminfo state reset sequence. However
there are two problems with this. The first is the general problem of
interrupting an operation in the middle; if the program was abruptly
suspended partway through sending the terminal an escape sequence, the
terminal may be in a mode where it will interpret part of your reset
sequence as part of the incomplete escape sequence.

The second problem is that sometimes, part of 'resetting' things is
program dependent. The big example is where you should (re)position the
cursor. The cursor may have been put in an arbitrary and potentially
strange position and thus needs to be repositioned somewhere useful,
or it might be in a perfectly sensible location already and you should
leave it alone. The first case is typical of a full screen program like
_vi_ (where the cursor will usually be repositioned to the bottom of
the screen); the second case is typical of a program that just uses
readline. The shell generally can't know which program is which.