[9front] rc interrupt regression

[Michael Forney <mforney@mforney.org>]

For a little while, I've noticed unexpected behavior with rc in rio
involving interrupts.

The issue can be reproduced fairly easily by cating a file with
enough lines to fill the window, then pressing del just enough times
so that the rc prompt is written. The next command you run is
dropped, with no indication in $status that it didn't succeed.

When rc is blocked on writing its prompt, the del press causes rio
to first scroll to the end of the window and then start a new proc
to send the interrupt. Scrolling the window unblocks the write of
the prompt, which succeeds. The interrupt then arrives, setting the
interrupt trap in rc.

At this point, rc has written the prompt, has a pending interrupt,
and now is waiting on the next line of input. If we type a command
such as `echo hello`, the command is parsed successfully, and then
pushed onto the runq.  Xrdcmds returns, then dotrap() finally detects
the interrupt and the command is dropped, without setting $status.

This behavior was introduced in commit
189731aad01e09db1807c78af421c615ed3a3242 rc: make it portable (for UNIX)

Specifically, the following hunk:

@@ -995,7 +1032,6 @@ Xrdcmds(void)
 			p->lex = 0;
 		} else
 			--p->pc;	/* re-execute Xrdcmds after codebuf runs */
-		ntrap = 0;	/* avoid double-interrupts during blocked writes */
 		start(codebuf, 2, p->local, p->redir);
 	}
 	lex = 0;

Adding back this line fixes the issue for me. Was this a deliberate
change needed for the unix port? If so, is there some other way to
solve this problem?