The shell should handle tty modes along with job control

[Dan Bernstein]

Why should a non-curses character-mode application have to catch SIGTSTP?

Obviously this is a fruitful source of bugs: if, for instance, I put rn
into the background and type bg a few times, it'll hang. I'm not
surprised. It isn't entirely obvious how to avoid the race conditions
involved in setting the tty modes correctly upon stop and restart. In
pty I was able to cheat a bit---this synchronization problem actually
becomes easier to solve when you have two processes. But getting the
average program to work correctly with job control is too difficult.

In contrast, it would be absolutely trivial to have the shell set tty
modes correctly when processes stop or restart. This would clear up
several conceptual problems with the current design, and would greatly
simplify many programs. It would also make future enhancements much
easier. Ever want to ^Z out of a program and change your stty settings?
You'd just have to add a few lines to your shell.

To extend this a bit: I have programs ``cbreak'' and ``char'' that do
nothing but change tty modes and invoke another program, making sure to
restore modes at the appropriate times. There's no reason they couldn't
be built into the shell. This means that applications like vi wouldn't
even have to find the terminal, let alone manipulate it.

Now I can simulate all the above features with pty, but I'm not going to
pretend that it's the right solution to these problems. Your shell
already talks intimately with a tty. Why is it necessary to subvert it
and use a pseudo-tty? Why can't it manage its own tty to provide the
facilities that applications need?

I hope this gives shell writers some ideas.

---Dan