[net.sources.bugs] vtrek termcap delay usage bug explained

howard@cyb-eng.UUCP (Howard Johnson) (10/13/85)

A number at the beginning of a termcap string specifies a delay (in
milliseconds) which must follow the escape sequence so the terminal
doesn't drop subsequent characters sent to it.  The delay is accomplished
by transmitting repeatedly a pad character ('\0' by default).
An asterisk ('*') following that number means that this much delay
is needed for each affected line (LINES - y) or character.

> But tell me, how does that relate tgetent(3) & tgoto(3)?  I didn't write
> vtrek [a game], so it was not my doing to use termcap(3) routines.
> However, tgoto(3) does not strip off the delay info and just dumps it onto
> the screen with escape and other stuff following it.  So what comes out
> [on the vt100] is a bunch of "5"s surrounding (and distorting) everything
> on the screen!  So what am I supposed to do?  [...]

The problem seems to be that the string returned by tgoto() was sent to
the terminal without sending it through tputs(), since tputs() interprets
termcap delays.  BTW, don't forget to set the

	extern short ospeed;

variable to tty.sg_ospeed (BSD/V7) or tty.c_cflag&CBAUD (USG).

Given:

outc(ch)	/* sends character to the terminal */
char ch;

then the appropriate fix would resemble this:

	tputs(tgoto(CM, col, row), 1, outc);
-- 
..!{seismo,topaz,mordor,harvard,gatech,nbires,ihnp4}!ut-sally!cyb-eng!howard
(ordered best to worst); also ..!{ut-ngp,shell}!cyb-eng!howard  +1 512 458 6609