| 1 |
On 03/19/2017 04:37 AM, Alan Mackenzie wrote: |
| 2 |
> Hello, Kai. |
| 3 |
> |
| 4 |
> On Sun, Mar 19, 2017 at 09:49:50 +0100, Kai Krakow wrote: |
| 5 |
>> Hello! |
| 6 |
> |
| 7 |
>> More and more of my Gentoo systems are exhibiting the following |
| 8 |
>> strange and unexpected behavior: |
| 9 |
> |
| 10 |
>> After ctrl+c'ing out of programs like tailf, SSH password prompts, in |
| 11 |
>> the middle of a shell scripts, the shell echo is not restored - that |
| 12 |
>> is: If I type characters I no longer see the characters (but they are |
| 13 |
>> received and can be executed by "enter"). If experiencing this, I have |
| 14 |
>> to ctrl+c again to discard what I was typing, the blindly type "reset" |
| 15 |
>> to reset the terminal, then echo is enabled again. |
| 16 |
> |
| 17 |
>> I'm not sure which update or configuration is causing this. It started |
| 18 |
>> out on our Gentoo servers some years ago (which I'm only SSH'ed into, |
| 19 |
>> no physical access), now since a few weeks, also my desktop machines are |
| 20 |
>> affected. I have no explanation for this. |
| 21 |
> |
| 22 |
>> But maybe anyone? |
| 23 |
> |
| 24 |
>> BTW: I know from the old times (some 15-20 years ago) that ctrl+c out |
| 25 |
>> of a program (i.e. rsync) that starts a subshell (i.e. ssh) that in |
| 26 |
>> turn shows a password prompt, will leave you with an echoless shell. |
| 27 |
>> But it shows up on almost any occasion now. |
| 28 |
> |
| 29 |
> It's been happening to me increasingly often in the last few |
| 30 |
> months/years. I don't like it. |
| 31 |
> |
| 32 |
> Here is a recipe for reproducing the phenomenon. A typical way of |
| 33 |
> invoking patch is by supplying the patch file to standard input: |
| 34 |
> |
| 35 |
> $ patch --dry-run < some-patch-file.diff |
| 36 |
> |
| 37 |
> . However if you accidentally omit the "<", like this: |
| 38 |
> |
| 39 |
> $ patch --dry-run some-patch-file.diff |
| 40 |
> |
| 41 |
> , the terminal will await you typing in the patch file. Instead, do a |
| 42 |
> ctrl-c. This leaves the terminal not echoing keystrokes. |
| 43 |
> |
| 44 |
> By the way, thanks for educating me about the existence of the command |
| 45 |
> `reset'. :-) |
| 46 |
> |
| 47 |
|
| 48 |
`stty echo` will probably fix it as well. |
| 49 |
|
| 50 |
I haven't seen this problem but I can reproduce it. It seems to rely on |
| 51 |
programs/scripts interrupting break and setting the terminal settings |
| 52 |
back the way they were. If a program/script does not do this properly, |
| 53 |
and it changes the tty echo state, it leaves echo off as well. |
| 54 |
|
| 55 |
When it happens, if you run `stty -a` do you see "-echo" in the results? |
| 56 |
If you do, whatever you ran turned echo off and didn't restore it on abort. |
| 57 |
|
| 58 |
If you want you can turn it off yourself using `stty -echo` for testing. |
| 59 |
|
| 60 |
The question is, is this the responsibility of bash itself after a |
| 61 |
script terminates? |
| 62 |
|
| 63 |
Dan |
Archives