9

Some command line interface tools return a broken console when canceled by CTRL+C. Sometimes the text is invisible, or there are graphic problems until I run the command reset.

(I use bash, but expect it is independent of the shell.)

Does this effect have a name? What causes this, and how can programmers prevent this in the tools? Is there a strategy how this problem is addressed in the major programming languages?

Jonas Stein
  • 4,078
  • 4
  • 36
  • 55
  • Related questions are https://unix.stackexchange.com/questions/401010/ , https://unix.stackexchange.com/questions/79684/ , https://unix.stackexchange.com/questions/164944/ , https://unix.stackexchange.com/questions/282514/ , and https://unix.stackexchange.com/questions/398291/ just for starters. See also https://superuser.com/questions/1259442/ . – JdeBP Nov 11 '17 at 16:53
  • stty sane for the grey beards – Thorbjørn Ravn Andersen Nov 11 '17 at 23:23

2 Answers2

14

A console sometimes needs a reset(1) (or some stty(1) command) because the state of a pseudo-terminal does not change when some process (e.g. a program started by your shell) terminates.

Read the tty demystified.

(I find the handling of pseudo-terminals and pseudottys the most difficult part of Linux)

Is there a strategy how this problem is addressed in the major programming languages?

A well-behaved program dealing with the terminal and changing its mode or line discipline should try hard to avoid crashing and issue the appropriate calls (see termios(3)) to put the terminal in the right state. BTW, libraries like ncurses or readline are helpful (but you need to call their cleanup routines appropriately).

See signal(7) and signal-safety(7). Avoiding crashing in your code is difficult. Read about undefined behavior.

An imperfect workaround could be to define a shell function which runs your program then does a reset (that could sometimes be inappropriate).

Basile Starynkevitch
  • 10,561
  • That workaround isn't great; sometimes reset can result in different stty settings from the original ones. – Bob Nov 11 '17 at 15:25
  • Yes, thanks for pointing that out. I added "imperfect". – Basile Starynkevitch Nov 11 '17 at 15:35
  • I have read your links, they were interesting, but it would be helpfull, if you could add a pointer to a section for this Q/A each. After reading tty demystified, I started stty -a > /tmp/test1 in bash then a command, which I cancelled. The terminal color was now red. stty -a > /tmp/test2 but test1 and test2 were exactly the same. – Jonas Stein Nov 12 '17 at 01:04
1

Responding to this problem isn't completely shell-independent. In zsh, there is the ttyctl builtin, which can "freeze" or "unfreeze" the tty mode. I don't think there's an equivalent in bash. The setty command in tcsh does the same thing, but more fine-grained: you can freeze individual settings.

Freezing the tty mode just means that zsh will remember the current mode, and if some future child changes it, the mode will be restored when the child suspends or terminates.

This will protect you from some of the bad effects of programs that crash or otherwise fail to clean up the terminal. You must remember to unfreeze if you want to make a change with stty, otherwise the shell will immediately undo whatever your stty did.

reset does more than restore stty modes, so you still might need it sometimes, but not often.

  • Indeed: I started stty -a > /tmp/test1 in bash then a command, which I cancelled. The terminal color was now red. stty -a > /tmp/test2 but test1 and test2 were exactly the same. I tried the same with tcsh, but I could not crash my command by CTRL+C. The colors remained fine. – Jonas Stein Nov 12 '17 at 01:10