Bug in man, more, or new terminal driver? (4.2BSD)

[Sam Quiring]

[]

This news really posts two bugs (I think).

When I use man on my home terminal (1200 baud over the phone lines) I
frequently stop the output as soon as I've seen what I want using the
"rubout" key (SIGINT).  When the 4.2 version of man prints a manual
page, it uses "more" as the pager.  In spite of making all the
corrections to "more" suggested in the last few months, I seem to have
a 50% chance of being left in a "normal" state after I hit rubout, or
in one of the following 3 states:  (a) CBREAK mode with no ECHO, or (b)
with underlining, or (c) standout mode still in effect.

Bug #1: CBREAK & -ECHO: I think this bug is in the new terminal
driver.  More puts the terminal into CBREAK -ECHO when it begins.  More
catches SIGINT, where it resets the crt to what it was before More
started.  However, before resetting the terminal the signal handler
attempts to clear underlining and standout mode.  But, if man, the
program that fork(2)ed more, gets the SIGINT first, then man exit(2)s
back to csh, which will [apparently] set up a new process group for the
next csh command.  So when more tries to reset the terminal, it is
suddenly no longer in the "distinguished process group for that
terminal".  This is from tty(4):

	"When using the new terminal driver with the LTOSTOP bit set in
	the local modes, a process is prohibited from writing on its
	control terminal if it is not in the distinguished process
	group for that terminal.  Processes which are holding or
	ignoring SIGTTOU signals, which are orphans, or which are in
	the middle of a vfork (2) are excepted and allowed to produce
	output."

I do not believe that the new terminal driver does this:  more is an
orphan, so it should be allowed to produce output, right?.  I checked,
and more does indeed get a SIGTTOU under the conditions described under
Bug #1.  What gives?  Ignoring the SIGTTOU does not help either.
The solution, by the way, was to have man do a wait(2) until all children
have exited.

Bug#2:  Underlining or Standout not turned off.  I have been unable to
fix this one.  [My copy of] More has two internal state variables that
keep track of underlining mode and standout mode.  However, more
buffers all of its output, so these variables don't reflect reality
very often.  I added a few fflush(stdout) calls whenever a state change
was happening in hopes that the real terminal state and the variables
would agreed.  This seems to help, but it does not fix the bug
entirely.  I believe what is happening is that the the characters are
being buffered for output to the terminal, but fflush is returning
before the characters are actually written.  Thus, the state variable
says, "we are back from fflush, the terminal must not be in standout
mode anymore."  What happens is that SIGINT comes in and flushes the
output buffer =>before the characters actually get written<=, so the
terminal stays in standout mode.  Does this sound reasonable?  How
do I fix this?