freebsd stable - Jan 2017 - reset not working like 70% of the time

Hi,

does anyone suffer from this too ? Right now (and for several last
years) a 100% decent way to reset a terminal session (for instance,
after a connection reset, after acidentally displaying a binary file
with symbols that are treated as terminal control sequence, after
breaking a cu session, etc) is to launch midnight commander and then
quit from it. And the reset is working like in 30% of cases only. Unlike
in Linux, where it's 100% functional.

Am I the only person seeing this ?

Eugene.

Hi!
> does anyone suffer from this too ? Right now (and for several last
> years) a 100% decent way to reset a terminal session (for instance,
> after a connection reset, after acidentally displaying a binary file
> with symbols that are treated as terminal control sequence, after
> breaking a cu session, etc) is to launch midnight commander and then
> quit from it. And the reset is working like in 30% of cases only.
[...]
> Am I the only person seeing this ?
I had some cases in the past where xterm was hanging, too -- but
not with *that* high rate of problems.

Most of the times, xterm's Full Reset options works fine.

The question is: how to debug that... ?

-- 
pi at opsec.eu            +49 171 3101372                         3 years to go
!

On Wed, Jan 25, 2017 at 4:52 AM, Eugene M. Zheganin <emz at norma.perm.ru>
wrote:
> does anyone suffer from this too ? Right now (and for several last
> years) a 100% decent way to reset a terminal session (for instance,
> after a connection reset, after acidentally displaying a binary file
> with symbols that are treated as terminal control sequence, after
> breaking a cu session, etc) is to launch midnight commander and then
> quit from it. And the reset is working like in 30% of cases only. Unlike
> in Linux, where it's 100% functional.
>
Using an application like that to reset the terminal is dubious at best.
You are at the mercy of how exactly it does terminal conditioning, and
nobody makes any promises about its actual behavior. In fact it could be
argued that, if it does not put the terminal back exactly the way it found
it, the application is broken. But this is actually impossible to do
correctly as the application can't know the terminal's full ANSI X3.64
state. Additionally there's a bit of a "religious issue" around
whether
full screen applications use xterm's alternate screen (and whether xterm
even has that enabled) which will save and restore more of the X3.64 state
around the application.

"tput reset; stty sane" (or just "reset") should usually put
the terminal
into a sensible state. If it doesn't, figure out whether the part that
isn't happening is a termios or a terminfo setting and focus on that part.
Check if xterm has "Enable alternate screen switching" checked on the
control-middle button menu.

-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at
sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net