Orphaned Response

dat at hpcnof.UUCP dat at hpcnof.UUCP
Wed Oct 2 02:29:00 AEST 1985


/***** hpcnof:net.sources / birtch!oleg /  6:19 pm  Sep 25, 1985*/
> I have found that vt52 terminals on our Pyramid 90x ( 4.2 & V5, in 
> 4.2 BSD univerce) work just fine. vt100 on the other hand did not.
> I traced the problem to TERMCAP : vt100 entry contains the length of
> character sequence in front of  "cm", "cl" and some other sequences.
> That I fixed by setting environment var TERMCAP to be the modifyed
> vt100 entry from /etc/termcap ( without sequence length :  "cm=\E[..." 
> instead of "cm=5\E[...")

	Umm...it turns out that the number in front of the termcap
entry is defined to be the delay in milliseconds to send an appropriate
number of padding characters (usually a NULL - the exact number being a
function, logically, of how fast your terminal is receiving data) after
the desired operation.  So, for example, if your termcap entry is
		cm=5\EC
then the sequence that would be sent to the screen (assume that the
receive speed is one character per millisecond (?))

	<escape> C <null> <null> <null> <null> <null>

The fact that someone modified your termcap entries to reflect the number 
of characters in the entry is weird.  It means that since that modification
your terminals have been running just a tad slower than they could have
(maybe - this assumes that you aren't misreading it).

	Furthermore, some delays can be proportional to the number of lines
affected by the operation.  For example, the Clear to End of Screen could
be set to  "cd=3*\ED" which would mean that it would take a three millisecond
delay PER LINE AFFECTED by the operation, the exact number to be figured out
by the terminal driver.

	Termcap is a strange puppy...

						--- Dave Taylor
						Hewlett Packard Corp.

						ihnp4!hpfcla!d_taylor



More information about the Comp.sources.unix mailing list