Re: bin/51385: NetBSD-7/amd64 tset(1) requires subsequent stty erase '^?'

[mlelstv%serpens.de@localhost (Michael van Elst)]

The following reply was made to PR bin/51385; it has been noted by GNATS.

From: mlelstv%serpens.de@localhost (Michael van Elst)
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: bin/51385: NetBSD-7/amd64 tset(1) requires subsequent stty erase '^?'
Date: Tue, 2 Aug 2016 06:08:18 +0000 (UTC)

 mm_lists%pulsar-zone.net@localhost (Matthew Mondor) writes:
 
 >After an update to NetBSD-7 from NetBSD-6, I noticed that in some
 >applications like vi(1) and vim(1) the backspace stopped working and
 >issued instances of ^? instead.  Only as the root user, with the same
 >editor configuration, and in all of: the native text console
 >(wsdisplay0 at radeondrmkmsfb0 in this case), xterm and urxvt
 >(rxvt-unicode).  On the other hand, if typing ^H (control-h) instead of
 >backspace, it works.
 
 tset got broken much earlier when we replaced termcap with terminfo.
 It then ignored the terminfo definitions for the backspace key. This
 was fixed for NetBSD-7, it now follows the terminfo and behaves again
 like e.g. FreeBSD.
 
 The issue with what character (BS or DEL) is used by the backspace key
 is very old and we also do not use it consistently. This is in particular
 an issue with people using Linux as their user interface because
 Linux tried to end this by declaring DEL to be the one and only
 right setting. They even patched xterm once to default to use DEL
 together with a patched termcap entry. Of course this doesn't really
 work unless the whole world takes the patches.
 
 
 >I'm not too familiar with tset(1) and terminfo(3) or the way they
 >exchange that information, but it would appear that the backspace
 >character is not being reported correctly on NetBSD-7.  The reset(1)
 >command also triggers the issue.
 
 terminfo says that the backspace key for xterm ($TERM) does emit BS and 
 tset configures the tty layer to interpret BS as the erase key.
 
 For local ttys (e.g. console) $TERM should match the terminal
 and tset is the right thing to use. But for remote sessions
 (e.g. ssh) $TERM doesn't often match the terminal (in particular
 not for an X terminal emulator running on Linux). ssh will
 also pass through tty layer settings, so using tset here doesn't
 make sense. That's why it was removed from the default .cshrc
 files. Few people use real terminals, most use ssh from another
 system.
 
 If anything, postinstall should remove the tset call in .cshrc
 when upgrading. But that might be possible for the root account,
 but not for arbitrary rc files from user accounts.
 
 -- 
 -- 
                                 Michael van Elst
 Internet: mlelstv%serpens.de@localhost
                                 "A potential Snark may lurk in every tree."