CTRL + Cの後でコンソールをリセットする必要がある場合があるのはなぜですか
一部のコマンドラインインターフェイスツールは、CTRL+Cによってキャンセルされると、壊れたコンソールを返します。テキストが表示されない場合や、resetコマンドを実行するまでグラフィックに問題がある場合があります。
（私はbashを使用していますが、シェルから独立していることを期待しています。）
この効果には名前がありますか？何が原因で、プログラマはこれをツールでどのように防ぐことができますか？主要なプログラミング言語でこの問題に対処する方法はありますか？
疑似端末の状態は次の場合に変化しないため、コンソールには reset(1) （またはいくつかの stty(1) コマンド）が必要になることがあります。一部のプロセス（シェルによって開始されたプログラムなど）が終了します。
tty demystified をお読みください。
（私は pseudo-terminals およびpseudottysの処理がLinuxの最も難しい部分であることを発見しました）
主要なプログラミング言語でこの問題に対処する方法はありますか？
端末を処理し、そのモードまたは回線規則を変更する適切に動作するプログラムは、クラッシュを回避し、適切な呼び出し（ termios（3） を参照）を発行して、端末を正しい状態にする必要があります。ところで、 ncurses または readline のようなライブラリは役に立ちます（ただし、それらのクリーンアップルーチンを適切に呼び出す必要があります）。
signal（7） および signal-safety（7） を参照してください。コードのクラッシュを回避することは困難です。 未定義の動作 についてお読みください。
不完全な回避策は、プログラムを実行してresetを実行するシェル関数を定義することです（これは、不適切な場合があります）。
この問題への対応は、完全にシェルから独立しているわけではありません。 zshには、ttyctlビルトインがあり、ttyモードを「フリーズ」または「フリーズ解除」できます。 bashに同等のものはないと思います。 tcshのsettyコマンドも同じことを行いますが、より細かく、個々の設定をフリーズできます。
Ttyモードをフリーズするとは、zshが現在のモードを記憶することを意味し、将来の子がそれを変更した場合、子が中断または終了したときにモードが復元されます。
これにより、クラッシュしたり、ターミナルのクリーンアップに失敗したりするプログラムの悪影響から保護されます。 sttyを使用して変更を加える場合は、フリーズを解除することを忘れないでください。そうしないと、シェルはsttyが行った処理を直ちに元に戻します。
resetはsttyモードを復元するだけではありません。そのため、場合によっては必要になることもありますが、頻繁には必要ありません。