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

[Matthew Mondor <mm_lists%pulsar-zone.net@localhost>]

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

From: Matthew Mondor <mm_lists%pulsar-zone.net@localhost>
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 04:05:25 -0400

 On Tue,  2 Aug 2016 06:10:02 +0000 (UTC)
 mlelstv%serpens.de@localhost (Michael van Elst) wrote:
 
 >  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.
 
 I understand this.  I use local terminals as much as remote ones, since
 I also use NetBSD as development workstation and desktop as well as
 firewalls and servers (and rarely use Linux, except to
 setup/maintain/configure it for others).
 
 I remember that when using actual serial terminals to NetBSD systems,
 tset was indeed necessary, and in the past, when using urxvt (or
 previously, aterm) to ssh on some remote systems.  It makes sense that
 it's not always necessary (and I haven't used it in my user shell
 configuration in a while).  At rare occasions, I also had to set custom
 non-default TERM settings, generally over ssh from xterm or urxvt so
 that [n]curses applications on a remote system I connected to worked
 (and remote tset wasn't enough).
 
 An issue with completely avoiding tset is that the reset command is
 often the simplest way to recover a terminal that has been rendered in
 an unusable state by i.e. inadvertently printing some binary, or broken
 or crashing software changing its settings and leaving the terminal in
 an inconsistent state.
 
 I noticed that I used to set vt220 in /etc/ttys (and consequently
 default local TERM for ttyEx), and wondered if my switch back to wsvt25
 wasn't responsible for my recent tset issues on NetBSD-7, but I tested
 with vt220 with the same results, and noticed in the terminfo database
 that wsvt25 mostly fallsback to vs220 anyway including for kbs and dch1.
 
 If I understand, you are saying that there is nothing we can fix, are
 recommending that I create an alternate terminfo vt220 or wsvt25 entry
 variant, as well as an rxvt variant, or that I explicitely configure
 their backspace independently (wscons and urxvt), and that xterm has
 been broken by freedesktop.  Yet I don't remember needing to do this
 since NetBSD 1.5.  So every NetBSD user with a PC and PS/2 keyboard
 must now have a special custom configuration, or completely avoid
 tset/reset.  But at least you didn't tell me to strictly stick to
 hjklx/ctrl-h :)
 
 A good reason for having kept PS/2 was for debugging and reliability,
 as the bootloader and DDB input often had issues with USB (I'm not sure
 if that's still often the case).
 
 I can manage with a custom wscons and urxvt configuration.  I also
 could help to provide man page or documentation patches to better
 document this issue and offer configuration examples.  On the other
 hand I'm not convinced that it's the best possible solution...
 
 If PS/2 IBM-style keyboards are sending different codes, couldn't it not
 be considered one of the architecture-intimate pckbd(4)'s role to
 possibly help (i.e. via lower level layout/code mappings rather than
 encodings), perhaps eventually configurable via a potential pckbdctl(8)
 or similar?
 
 -- 
 Matt