At Tue, 23 Nov 2021 18:31:38 -0500, Greg Troxel <gdt%lexort.com@localhost> wrote:
Subject: Re: wsvt25 backspace key should match terminfo definition
>
> Johnny Billquist <bqt%softjar.se@localhost> writes:
>
> >> For vt320 (where it *is* configurable) terminfo has
> >>
> >> $ infocmp -1 vt320 | grep kbs
> >> kbs=^?,
> >
> > Which I think it should be.
>
>
> But what does kbs mean?
>
> - the ASCII character sent by the computer to move the cursor left?
> - the ASCII character sent by the BS key?
> - the ASCII character sent by the DEL key that the uses uss to delete left?
The answer to your question is actually clearly documented in the
terminfo(5) manual page:
key_backspace kbs kb sent by backspace key
(note I fixed the typo (s/set/sent/) in my /usr/src/lib/libterminfo/term.h)
I.e. if you have a terminal keyboard that has a key with the "Backspace"
label, and another key with the "Delete" label, (or their "moral"
equivalents, label-wise) then the terminfo entry's "kbs" value should
give the character sequence sent when the user presses the "Backspace"
key, and it should also have a value for "kdch1" giving the sequence
sent when the user presses the "Delete" key:
key_dc kdch1 kD sent by delete-character
key
For a configurable terminal (e.g. a real VT220 in vt100 mode) there
should be a separate terminfo entry for the terminal in that different
mode. In NetBSD's terminfo file this is currently "vt220d" (or
"vt220-old", if that applies better to the actual terminal and/or
keyboard in use).
Note also, just to be more pedantic, the "k" prefix on terminfo(5)
"Code" names (and the corresponding "key_" prefix on the "Long name"
names) is the clue that the value for these codes is to represent the
sequence sent by the terminal. This has been true since the 1980s when
terminfo first came along.
Also, BTW, the tradition for which key was the interrupt key (i.e. the
one eventually modifiable using "stty intr") (and which key was "stty
erase") changed depending on where/when you were. Some say it had an
"East Coast / West Coast" division -- Bell Labs vs. UCB.
I began in the early 1980s with the Bell Labs tradition (and terminals
to match) that "stty intr" was set to ASCII DEL. Indeed that's all I
could do since I started with Unix V7. As I understood it at the time
this matched the Teletype "rubout" key that was used as the interrupt
key (though I never used a real Teletype back then) [from tty(4) in the
Unix 7th edition manual]:
During input, erase and kill processing is normally done. By default,
the character ‘#’ erases the last character typed
[[ .... ]]
DEL (Rubout) is not passed to a program but generates an
interrupt signal which is sent to all processes with
the associated control terminal. Normally each such
process is forced to terminate, but arrangements may be
made either to ignore the signal or to receive a trap
to an agreed-upon location. See signal(2).
Original V7 stty(1) didn't even let one change the "interrupt" key
(though I believe V7's tty(4) TIOCSETP command would allow it to be
changed).
Of course back then the tty line discipline didn't do live erase or kill
processing, and so the erase character was often left as "#" to avoid
confusion (and "stty kill" was '@' -- modern email was a long way off!).
The tradition of "stty intr" being ASCII DEL (by default) carried on
into the AT&T releases as well, just as one would expect. However even
right up to Unix System V Release 4.2 (about 1992) they hung on to '#'
being the default erase character [this from SysVr4.2's termio(7)]:
INTR (Rubout or ASCII DEL) generates a SIGINT signal. SIGINT is
sent to all frequent processes associated with the control‐
ling terminal. Normally, each such process is forced to ter‐
minate, but arrangements may be made either to ignore the
signal or to receive a trap to an agreed upon location. [See
signal(5)].
ERASE (#) erases the preceding character. It does not erase beyond
the start of a line, as delimited by a NL, EOF, EOL, or EOL2
character.
Leaving "stty erase" as '#' changed quickly once one upgraded to a new
enough system to have "ECHOE" (and "ECHOK") processing, including for
BSD with the "new crt" line discipline, where live erase and kill
processing could be enabled. Then one would set the erase character to
what was most logical for the keyboard one was using.
In Research Unix this all happened with the Unix 8th edition when the
default for the tty line discipline's erase character was also changed
to be the ASCII BS character, and the new "nttyld.c" implemented live
erase and kill processing though none of this was properly documented.
This is from V10's ttyld(4):
The erase character (backspace by default) erases the last‐typed char‐
acter. It will not erase beyond the beginning of a line or an end‐of‐
file character.
The interrupt character (default DEL) is not passed to a program but
sends signal to any processes in the process group of the stream; see
signal(2) and stream(4).
(The Research releases never really documented their "nttyld.c" driver
-- i.e. the one that does live erase and kill processing, though it is
hinted to in V10's stty(1) manual page with the "old" and "!old" options.)
All this gets me to the point of showing that it was those upstart
Berkeley dudes who first set the default "stty erase" character to DEL. :-)
Quite risky actually if you think of what will happen when you try to
transfer your new keyboard skills to one of those East Coast systems and
you don't pay attention to the difference in the tty drivers! Thank
goodness the tset(1) command now prints what's what.
From 4.3BSD's tty(4) describing the new "standard Berkeley terminal
driver":
During input, line editing is normally done, with the erase character
sg_erase (by default, DELETE) logically erasing the last character
typed and the sg_kill character (default, ^U: control‐U) logically
erasing the entire current input line. These characters never erase
beyond the beginning of the current input line or an eof. These char‐
acters may be entered literally by preceding them with ‘\’; the ‘\’
will normally be erased when the character is typed.
[[ .... ]]
^C t_intrc (ETX) generates a SIGINT signal. This is the normal way
to stop a process which is no longer interesting, or to regain
control in an interactive program.
Personally, I stuck to the Bell Labs ways and always used the
"Backspace" key on my VT10x terminals as the key for "stty erase", and
the "Del" key as the key for "stty intr"; all the way back to when I ran
Research and AT&T Unixes, right up to when I had a real VT101 on the
console of some of my early (non-i386) NetBSD machines.
Also note the BSD tty(4) driver's default for "stty intr" being <CTRL-C>
as this also has its origins in the DEC world.
BTW, since this is tech-kern, note that the wscons(4) manual page tells
a little white lie when it suggests that when in "vt100" mode it "will
work sufficiently as a VT220 emulator." This fact is now documented in
/usr/share/misc/terminfo:
# Testing the emulator and reading the source code (NetBSD 2.0), it appears
# that "vt220" is inaccurate. There are a few vt220-features, but most of the
# vt220 screens in vttest do not work with this emulator.
There's a real mess of confusion related to thinking of wscons(4) (and
pc(4)/pcvt(4) before) as good enough to be like a vt220. In my twisted
view of the erase/kill/intr story I like to think it may actually have
started with the insistence of following the BSD tradition to have the
standard PC keyboard's "<- Backspace" key (i.e. the "big left-arrow" key
at the top right of the main group which was and is always the
"Backspace" key) to send a DEL character (instead of the more normally
expected "BS" character given its name and label). Since VT220s are the
most common terminal to insist on sending "DEL" from the logically
placed "erase the previous character key", well then choosing "vt220" as
one's terminal type meant avoiding confusion over terminfo's "kbs" value
and the default "stty erase" character. Also it's more progressive
sounding to have a vt220 instead of a vt100. As such pc(4), then
pcvt(4), and finally wscons(4), are described as "vt220" compatible and
have been made to work well enough for vi(1) to behave properly when
TERM=vt220.
Personally I think there is a massive over-use of "use=vt220" in
terminfo -- that should be reserved ONLY for true DEC VT derivatives and
updates of the real VT220.
BTW, my own local NetBSD source trees generally always have hacks to set
the physical console keyboard's backspace key to translate into an ASCII
BS character, though I use the physical console on x86 machines so
little any more that it hardly matters.
In any case in this modern day I think some people still fall far too
hard on their swords, er, keyboards to try to stick to and insist on the
idea that DEL _has_ to be the character for "stty erase" (at least for
anything "BSD"-ish).
--
Greg A. Woods <gwoods%acm.org@localhost>
Kelowna, BC +1 250 762-7675 RoboHack <woods%robohack.ca@localhost>
Planix, Inc. <woods%planix.com@localhost> Avoncote Farms <woods%avoncote.ca@localhost>
Attachment:
pgpz00JXUuEzK.pgp
Description: OpenPGP Digital Signature