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


Reply via email to