rcd@ico.UUCP (04/10/87)
I just stumbled into some very odd behavior in (what I would call) the System
V version of nroff. (It's a recent AT&T version, in any case, and the
problem isn't in BSD.)
Apparently an ESC (033; 0x1b) character in a string in the terminal-driving
tables causes nroff to output the escape, the next character (even if
null!) and then continue until it finds the end of the string.
Can anyone shed any light on why-the-hell this was necessary? It's just
one more complication in trying to make nroff mesh with a perverse printer.
The problem is that 033 can't occur as the last character of a string to be
output when generating a special character--if it is, nroff goes on to
output whatever string follows in memory!
If you know what's behind this, or if you too have stumbled into it, I'd
like to hear from you via email.
[In case anyone is curious why this is a problem--I already have to use
magic sequences to get eight-bit characters. The way I chose to do it is
to output a flag byte followed by the code I need with the top bit off.
The nroff output is post-processed to turn this two-character sequence into
a single 8-bit character. But if I need to generate the code 0233, that
wants to be encoded as flag-byte 033.]
--
Dick Dunn {hao,nbires,cbosgd}!ico!rcd (303)449-2870
...Are you making this up as you go along?