Current-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: 'getty' printing delay tokens in -current and netbsd-6

After some further research, I see (more) of what the issue has been.

The "putpad()" routine in getty/main.c was hard-coded to interpret the
delay value that could optionally be included at the _beginning_ of a
TERMCAP control-sequence string, which could include a precision down
to 0.1ms.

The TERMINFO delay token is given as "$<ms>" at the _end_ of a control
string.  When -current was switched over to terminfo, getty wouldn't find
a leading delay value, so just printed the whole string as given.  If
it included a delay token, that was just output as well.

The "vt100" entry in /usr/share/misc/termcap (netbsd-5) doesn't specify
delays for any control sequences.  Other related entries do use them--
"vt131" is of particular interest as it specifies a 50ms delay for the
clear-screen (cl) capability.

This would explain why there is no padding when using "vt100" as the
terminal type in netbsd-5.  When I set a terminal to "vt131" in
"/etc/ttys", I do get padding in netbsd-5 (observed on VT220 in "Display
Controls" mode).

So, at some point the "vt100" entry in the terminfo database grew delay
tokens on several control strings.  In normal operation the appropriate
terminfo output routines which interpret the delays will be used.

'getty', in trying to handle delay/padding itself, has fallen out of
sync with respect to the terminfo-style strings.  I suppose the rationale
of doing the padding internally was to avoid the overhead of the
term{cap,info} library just to initialize a terminal.

|/"\ John D. Baker, KN5UKS               NetBSD     Darwin/MacOS X
|\ / jdbaker[snail]mylinuxisp[flyspeck]com    OpenBSD            FreeBSD
| X  No HTML/proprietary data in email.   BSD just sits there and works!
|/ \ GPGkeyID:  D703 4A7E 479F 63F8 D3F4  BD99 9572 8F23 E4AD 1645

Home | Main Index | Thread Index | Old Index