Re: reset not working like 70% of the time

2017-01-27 Thread Torfinn Ingolfsen
On Wed, 25 Jan 2017 15:24:55 +0500
"Eugene M. Zheganin"  wrote:

> I'm seeing all of these in my konsole terminal window while working with

Does it also happen if you use another terminal emulator insted of konsole?
-- 
Torfinn Ingolfsen 
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: reset not working like 70% of the time

2017-01-25 Thread Brandon Allbery
On Wed, Jan 25, 2017 at 1:25 PM, Martin S. Weber  wrote:

> OP, try and create a minimal file with script that doesn't clean up your
> terminal
> on reset(1). Make sure it doesn't contain confidential information.
> Publish your
> environment (env | grep TERM) and this script file somewhere. Let others
> know the
>

Also include output of "stty -a" ideally both before and after the terminal
ends up in a weird state.

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: reset not working like 70% of the time

2017-01-25 Thread Martin S. Weber
On 2017-01-25 12:59:27, Brandon Allbery wrote:
> On Wed, Jan 25, 2017 at 4:52 AM, Eugene M. Zheganin 
> 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.

OP stated he's using konsole (KDE wannabe xterm).

OP, try and create a minimal file with script that doesn't clean up your 
terminal
on reset(1). Make sure it doesn't contain confidential information. Publish your
environment (env | grep TERM) and this script file somewhere. Let others know 
the
URL. Then we can actually begin to answer your original question, whether or not
we see this as well. You could also try to reproduce your problems with 
different
terminal emulators (xterm, freebsd console)

Regards,
-Martin
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: reset not working like 70% of the time

2017-01-25 Thread Brandon Allbery
On Wed, Jan 25, 2017 at 4:52 AM, Eugene M. Zheganin 
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
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: reset not working like 70% of the time

2017-01-25 Thread Kurt Jaeger
Hi!

> > I had some cases in the past where xterm was hanging, too -- but
> > not with *that* high rate of problems.
> 
> Hmm that doesn???t sound too good. Potentially exploitable bug? 

I assume so, yes. Needs more fuzzying 8-}

-- 
p...@opsec.eu+49 171 3101372 3 years to go !
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: reset not working like 70% of the time

2017-01-25 Thread Borja Marcos

> On 25 Jan 2017, at 11:15, Kurt Jaeger  wrote:
> 
> I had some cases in the past where xterm was hanging, too -- but
> not with *that* high rate of problems.

Hmm that doesn’t sound too good. Potentially exploitable bug? 





Borja.

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: reset not working like 70% of the time

2017-01-25 Thread Martin S. Weber
On 2017-01-25 11:15:17, Kurt Jaeger wrote:
> 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... ?

Use script(1) to record an offending session, including the reset. 
Then replay with script or cat or ... 

Regards,
-Martin
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: reset not working like 70% of the time

2017-01-25 Thread Eugene M. Zheganin
Hi.

On 25.01.2017 15:15, Kurt Jaeger wrote:
> 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... ?
>
A typical cases are:

- newlines aren't working properly, current line just got cleaned and
that's all (no scrolling up one line happens)
- mouse clicking produces some input symbols in the terminal line
- Ctrl-C stops working (just nothing happens)

I'm seeing all of these in my konsole terminal window while working with
local and remote hosts (mostly with remotes), an typing 'reset' usually
just does nothing. God bless the Midnight Commander !

Eugene.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: reset not working like 70% of the time

2017-01-25 Thread Kurt Jaeger
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... ?

-- 
p...@opsec.eu+49 171 3101372 3 years to go !
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"