How to mess up your tty: (sleep 3;vi)&;vi\n<wait 5 seconds>ZZfg\n

[Dan Bernstein]

If a vi starts up in the background while the tty is in mode X, it'll
read mode X from the tty before it stops for background output. When you
get out of the current application and get into vi, it'll make all sorts
of incorrect conclusions about the tty mode based on its earlier
reading. In particular, if mode X is character mode (as from another
copy of vi), it won't process carriage returns and newlines properly,
and it will ``restore'' the tty to mode X when it finishes.

This problem appears to be buried somewhere in curses. Apparently curses
doesn't try hard enough to make sure it's in the foreground before it
reads the tty modes. This is true under at least SunOS, Ultrix, and
every straight BSD machine I can find. I wonder whether it's true under
SVR4.

So where is this bug? How can it be fixed? Whose fault is it, anyway?

I hereby retract my statement from many months back that the only
available character-mode programs which handle job control correctly are
(1) my pty program; (2) curses applications, such as vi. (Most other
examples fall to even the simplest test: rn & then bg then bg then bg.)

My corrected statement is that I have *never* seen a character-mode
application which handles job control correctly. I think I have a
solution for the next version of pty, but this entire situation is
disgusting. Do none of us truly understand job control? (Chris Torek
excepted, of course. :-) )

Note that a shell which restores tty modes on its own will compensate
for these problems, but that cannot be considered a bug fix (the same
problem will happen when the shell forks off an interactive subshell).
A multiplexing model is infinitely cleaner. Of course, now that the
forward-thinking geniuses at POSIX and NIST have stuck us with the same
job control model until hell freezes over, we can't do a thing about it.

---Dan
``Joy to the world: vi has come.'' ---J.W.