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
