Disgusting kernel hack

[Henry Spencer]

Brian Beattie observes:

	What about lines longer than the terminal width.

	"stty line 80" may not work due to control chars.
	unless you want "more" in the kernel with the reading
	of /etc/termcap and all you will always end up with
	either a partial solution or will be able to handle
	only one type of terminal.

	beattie at mitre

I hate to tell you folks this, but the kernel is *already* keeping
track of what column you're at, so that it can do software-interpreted
tab stops properly.  I agree that there is a potential problem with
the handling of control characters, since the kernel's interpretation
of whether a particular character causes a column motion or not is
quite simplistic, but in practice this does not get in the way very
much.  Programs that deliberately emit control characters generally
are controlling the terminal directly, in CBREAK or RAW mode, and thus
bypass tty-driver pagination altogether.  Control characters spilled out
onto the terminal by doing something silly like catting a binary file
make a horrid mess anyway, and hence are not really an issue.  It
really isn't a problem, folks.

And John Owens follows it up with:

   And what about whether a terminal wraps or not? I'll stick with the
   traditional Unix definition of a line - a sequence of characters
   terminated by a \n.  Much more elegant. (And much better than systems
   like VMS or TOPS-10 with their commands like SET TERM/VT100 !!!)

If the terminal doesn't wrap, you simply set the line length to 0 (i.e.,
"ignore issues of line length").  If it wraps in some strange way, you
just give the line length as one character less than it really is, so
the terminal's oddities are ignored completely.  I know of at least two
screen-oriented programs that do this, and few people have ever noticed.
-- 
				Henry Spencer @ U of Toronto Zoology
				{allegra,ihnp4,linus,decvax}!utzoo!henry