| 1 |
Am Sun, 19 Mar 2017 10:17:02 +0100 |
| 2 |
schrieb Matthias Hanft <mh@×××××.de>: |
| 3 |
|
| 4 |
> Kai Krakow wrote: |
| 5 |
> > |
| 6 |
> > After ctrl+c'ing out of programs like tailf, SSH password prompts, |
| 7 |
> > in the middle of a shell scripts, the shell echo is not restored |
| 8 |
> |
| 9 |
> Not here, but something similar: Immediately after ctrl+c'ing, no |
| 10 |
> shell prompt is displayed (in fact, *nothing* is displayed) - but |
| 11 |
> it's just the display; I can enter a shell command (with echo, too) |
| 12 |
> which will be executed properly. Or just press the RETURN key on the |
| 13 |
> empty line to get the shell prompt again. |
| 14 |
> |
| 15 |
> This happens just on a single of my Gentoo systems (and not always, |
| 16 |
> but very often). |
| 17 |
> |
| 18 |
> Any idea? |
| 19 |
|
| 20 |
Yes, this can sneak upon you if you ctrl+c a program with child |
| 21 |
processes, and part of the teardown is that a child displays a line |
| 22 |
after control has already been returned to the shell. |
| 23 |
|
| 24 |
What happens now is: Your shell displays the prompt, the child process |
| 25 |
echos a carriage return and echos text, overwriting your prompt, |
| 26 |
and putting a newline, child now also exits. If your prompt was long |
| 27 |
enough, you may still see the rest of it. You end up with a sole |
| 28 |
blinking cursor on an empty line. Hitting enter produces a new shell |
| 29 |
prompt. |
| 30 |
|
| 31 |
There's no way to work around it except by maybe putting a sleep inside |
| 32 |
the PS1 variable. But I'm sure you don't want that. ;-) |
| 33 |
|
| 34 |
Tho, thinking about this, your case may have the same underlying bug in |
| 35 |
common: delayed termination of child processes. |
| 36 |
|
| 37 |
-- |
| 38 |
Regards, |
| 39 |
Kai |
| 40 |
|
| 41 |
Replies to list-only preferred. |
Archives