Re: [gentoo-user] Shell echo missing after ctrl+c

2017-03-19 Thread Dale
Walter Dnes wrote:
> On Sun, Mar 19, 2017 at 09:49:50AM +0100, Kai Krakow wrote
>> Hello!
>>
>> More and more of my Gentoo systems are exhibiting the following
>> strange and unexpected behavior:
>>
>> After ctrl+c'ing out of programs like tailf, SSH password prompts, in
>> the middle of a shell scripts, the shell echo is not restored - that
>> is: If I type characters I no longer see the characters (but they are
>> received and can be executed by "enter"). If experiencing this, I have
>> to ctrl+c again to discard what I was typing, the blindly type "reset"
>> to reset the terminal, then echo is enabled again.
>   "It's not a bug; it's a feature".  It's caused by some programs.  See
> http://askubuntu.com/questions/171449/shell-does-not-show-typed-in-commands-reset-works-but-what-happened
> for a detailed explanation.  Executive summary... some programs, e.g.
> vim, can be run from the command line, and they accept certain control
> characters (CTRL-V, CTRL-I, etc) as valid input.  These characters would
> normally be echo'd back to the user's terminal by the kernel's tty
> subsystem.  This would foul up the application's screen display.  To
> avoid that, the application turns off echoing to the tty when it starts
> up.  It also restores echoing ***IF IT EXITS PROPERLY***.  This also
> applies to when a program issues a password prompt, where you obviously
> want echoing turned off.  If killed with CTRL-C or "kill -9" or "kill
> -15", it doesn't have a chance to restore echoing, and you get the
> situation you described.
>


So, it was intentional.  Why am I not surprised.  It's still annoying. 
I can see why they did it based on your post but it's still annoying. 

Dale

:-)  :-) 



Re: [gentoo-user] Shell echo missing after ctrl+c

2017-03-19 Thread Walter Dnes
On Sun, Mar 19, 2017 at 09:49:50AM +0100, Kai Krakow wrote
> Hello!
> 
> More and more of my Gentoo systems are exhibiting the following
> strange and unexpected behavior:
> 
> After ctrl+c'ing out of programs like tailf, SSH password prompts, in
> the middle of a shell scripts, the shell echo is not restored - that
> is: If I type characters I no longer see the characters (but they are
> received and can be executed by "enter"). If experiencing this, I have
> to ctrl+c again to discard what I was typing, the blindly type "reset"
> to reset the terminal, then echo is enabled again.

  "It's not a bug; it's a feature".  It's caused by some programs.  See
http://askubuntu.com/questions/171449/shell-does-not-show-typed-in-commands-reset-works-but-what-happened
for a detailed explanation.  Executive summary... some programs, e.g.
vim, can be run from the command line, and they accept certain control
characters (CTRL-V, CTRL-I, etc) as valid input.  These characters would
normally be echo'd back to the user's terminal by the kernel's tty
subsystem.  This would foul up the application's screen display.  To
avoid that, the application turns off echoing to the tty when it starts
up.  It also restores echoing ***IF IT EXITS PROPERLY***.  This also
applies to when a program issues a password prompt, where you obviously
want echoing turned off.  If killed with CTRL-C or "kill -9" or "kill
-15", it doesn't have a chance to restore echoing, and you get the
situation you described.

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications



Re: [gentoo-user] Shell echo missing after ctrl+c

2017-03-19 Thread Daniel Frey
On 03/19/2017 04:37 AM, Alan Mackenzie wrote:
> Hello, Kai.
> 
> On Sun, Mar 19, 2017 at 09:49:50 +0100, Kai Krakow wrote:
>> Hello!
> 
>> More and more of my Gentoo systems are exhibiting the following
>> strange and unexpected behavior:
> 
>> After ctrl+c'ing out of programs like tailf, SSH password prompts, in
>> the middle of a shell scripts, the shell echo is not restored - that
>> is: If I type characters I no longer see the characters (but they are
>> received and can be executed by "enter"). If experiencing this, I have
>> to ctrl+c again to discard what I was typing, the blindly type "reset"
>> to reset the terminal, then echo is enabled again.
> 
>> I'm not sure which update or configuration is causing this. It started
>> out on our Gentoo servers some years ago (which I'm only SSH'ed into,
>> no physical access), now since a few weeks, also my desktop machines are
>> affected. I have no explanation for this.
> 
>> But maybe anyone?
> 
>> BTW: I know from the old times (some 15-20 years ago) that ctrl+c out
>> of a program (i.e. rsync) that starts a subshell (i.e. ssh) that in
>> turn shows a password prompt, will leave you with an echoless shell.
>> But it shows up on almost any occasion now.
> 
> It's been happening to me increasingly often in the last few
> months/years.  I don't like it.
> 
> Here is a recipe for reproducing the phenomenon.  A typical way of
> invoking patch is by supplying the patch file to standard input:
> 
> $ patch --dry-run < some-patch-file.diff
> 
> .  However if you accidentally omit the "<", like this:
> 
> $ patch --dry-run some-patch-file.diff
> 
> , the terminal will await you typing in the patch file.  Instead, do a
> ctrl-c.  This leaves the terminal not echoing keystrokes.
> 
> By the way, thanks for educating me about the existence of the command
> `reset'.  :-)
> 

`stty echo` will probably fix it as well.

I haven't seen this problem but I can reproduce it. It seems to rely on
programs/scripts interrupting break and setting the terminal settings
back the way they were. If a program/script does not do this properly,
and it changes the tty echo state, it leaves echo off as well.

When it happens, if you run `stty -a` do you see "-echo" in the results?
If you do, whatever you ran turned echo off and didn't restore it on abort.

If you want you can turn it off yourself using `stty -echo` for testing.

The question is, is this the responsibility of bash itself after a
script terminates?

Dan




Re: [gentoo-user] Shell echo missing after ctrl+c

2017-03-19 Thread Alan Mackenzie
Hello, Kai.

On Sun, Mar 19, 2017 at 09:49:50 +0100, Kai Krakow wrote:
> Hello!

> More and more of my Gentoo systems are exhibiting the following
> strange and unexpected behavior:

> After ctrl+c'ing out of programs like tailf, SSH password prompts, in
> the middle of a shell scripts, the shell echo is not restored - that
> is: If I type characters I no longer see the characters (but they are
> received and can be executed by "enter"). If experiencing this, I have
> to ctrl+c again to discard what I was typing, the blindly type "reset"
> to reset the terminal, then echo is enabled again.

> I'm not sure which update or configuration is causing this. It started
> out on our Gentoo servers some years ago (which I'm only SSH'ed into,
> no physical access), now since a few weeks, also my desktop machines are
> affected. I have no explanation for this.

> But maybe anyone?

> BTW: I know from the old times (some 15-20 years ago) that ctrl+c out
> of a program (i.e. rsync) that starts a subshell (i.e. ssh) that in
> turn shows a password prompt, will leave you with an echoless shell.
> But it shows up on almost any occasion now.

It's been happening to me increasingly often in the last few
months/years.  I don't like it.

Here is a recipe for reproducing the phenomenon.  A typical way of
invoking patch is by supplying the patch file to standard input:

$ patch --dry-run < some-patch-file.diff

.  However if you accidentally omit the "<", like this:

$ patch --dry-run some-patch-file.diff

, the terminal will await you typing in the patch file.  Instead, do a
ctrl-c.  This leaves the terminal not echoing keystrokes.

By the way, thanks for educating me about the existence of the command
`reset'.  :-)

> -- 
> Regards,
> Kai

> Replies to list-only preferred.

-- 
Alan Mackenzie (Nuremberg, Germany).



Re: [gentoo-user] Shell echo missing after ctrl+c

2017-03-19 Thread tuxic
On 03/19 10:17, Matthias Hanft wrote:
> Kai Krakow wrote:
> > 
> > After ctrl+c'ing out of programs like tailf, SSH password prompts, in
> > the middle of a shell scripts, the shell echo is not restored
> 
> Not here, but something similar: Immediately after ctrl+c'ing, no shell
> prompt is displayed (in fact, *nothing* is displayed) - but it's just
> the display; I can enter a shell command (with echo, too) which will
> be executed properly. Or just press the RETURN key on the empty line
> to get the shell prompt again.
> 
> This happens just on a single of my Gentoo systems (and not always,
> but very often).
> 
> Any idea?
> 
> -Matt
> 
> 
Hi,

I haven't experienced this yet...but  the command

'reset'

will reset (hence the name... ;) the terminal to
normal. This also helps, if the terminal got confused
after accidentally cat'ing a binary...

Cheers
Meino





Re: [gentoo-user] Shell echo missing after ctrl+c

2017-03-19 Thread Matthias Hanft
Kai Krakow wrote:
> 
> After ctrl+c'ing out of programs like tailf, SSH password prompts, in
> the middle of a shell scripts, the shell echo is not restored

Not here, but something similar: Immediately after ctrl+c'ing, no shell
prompt is displayed (in fact, *nothing* is displayed) - but it's just
the display; I can enter a shell command (with echo, too) which will
be executed properly. Or just press the RETURN key on the empty line
to get the shell prompt again.

This happens just on a single of my Gentoo systems (and not always,
but very often).

Any idea?

-Matt




Re: [gentoo-user] Shell echo missing after ctrl+c

2017-03-19 Thread Dale
Kai Krakow wrote:
> Hello!
>
> More and more of my Gentoo systems are exhibiting the following
> strange and unexpected behavior:
>
> After ctrl+c'ing out of programs like tailf, SSH password prompts, in
> the middle of a shell scripts, the shell echo is not restored - that
> is: If I type characters I no longer see the characters (but they are
> received and can be executed by "enter"). If experiencing this, I have
> to ctrl+c again to discard what I was typing, the blindly type "reset"
> to reset the terminal, then echo is enabled again.
>
> I'm not sure which update or configuration is causing this. It started
> out on our Gentoo servers some years ago (which I'm only SSH'ed into,
> no physical access), now since a few weeks, also my desktop machines are
> affected. I have no explanation for this.
>
> But maybe anyone?
>
> BTW: I know from the old times (some 15-20 years ago) that ctrl+c out
> of a program (i.e. rsync) that starts a subshell (i.e. ssh) that in
> turn shows a password prompt, will leave you with an echoless shell.
> But it shows up on almost any occasion now.
>

I don't have a solution but wanted to reply to say that this happens to
me too.  I have a regular desktop running KDE.  I use Konsole for most
of my command line activity.  I've noticed that this happens with a lot
of programs.  It has been happening so long, I thought maybe it was the
new way things are done.  It is aggravating and confusing at times. 

You are not alone on this.  I'm hoping someone will post a fix. 

Dale

:-)  :-) 



[gentoo-user] Shell echo missing after ctrl+c

2017-03-19 Thread Kai Krakow
Hello!

More and more of my Gentoo systems are exhibiting the following
strange and unexpected behavior:

After ctrl+c'ing out of programs like tailf, SSH password prompts, in
the middle of a shell scripts, the shell echo is not restored - that
is: If I type characters I no longer see the characters (but they are
received and can be executed by "enter"). If experiencing this, I have
to ctrl+c again to discard what I was typing, the blindly type "reset"
to reset the terminal, then echo is enabled again.

I'm not sure which update or configuration is causing this. It started
out on our Gentoo servers some years ago (which I'm only SSH'ed into,
no physical access), now since a few weeks, also my desktop machines are
affected. I have no explanation for this.

But maybe anyone?

BTW: I know from the old times (some 15-20 years ago) that ctrl+c out
of a program (i.e. rsync) that starts a subshell (i.e. ssh) that in
turn shows a password prompt, will leave you with an echoless shell.
But it shows up on almost any occasion now.

-- 
Regards,
Kai

Replies to list-only preferred.