ランダムなコンソール出力が端末を壊さないようにする方法は？

で壊れた端末から回復する方法を示す多くの質問がSEにありますcat /dev/urandom。この問題に慣れていない人のために-ここでそれが何であるかについて：

1. 実行cat /dev/urandomまたは同等（たとえばcat binary_file.dat）。
2. ごみが印刷されます。

3. コマンドが終了した後でも端末がゴミを出力し続けることを除いて、それは大丈夫でしょう！これは、実際にはg ++出力である誤ってレンダリングされたテキストのスクリーンショットです。

   

   私は、C ++エラーが時々不可解すぎることについて人々は正しかったと思います！

通常の解決策はを実行stty sane && resetすることですが、これが発生するたびに実行するのは面倒です。

そのため、この質問で私が注目したいのは、これが起こる元の理由と、そのようなコマンドが発行された後に端末が壊れないようにする方法です。問題のあるコマンドをtrやにパイプするなどのソリューションを探しているわけではありません。xxdこれには、実際に実行/印刷する前にプログラム/ファイルがバイナリを出力し、そのようなデータを出力するたびに記憶する必要があることを知る必要があるためです。

URxvt、PuTTY、Linuxフレームバッファーで同じ動作に気づいたので、これは端末固有の問題ではないと思います。私の主な疑いは、ランダムな出力に文字エンコーディングを反転するANSIエスケープコードが含まれていることです（実際、cat /dev/urandomもう一度実行すると、端末が壊れない可能性があり、これがこの理論を裏付けているようです）。これが正しい場合、このエスケープコードは何ですか？それを無効にする標準的な方法はありますか？

いいえ：

• 「無効にする」標準的な方法はありません。
• 破損の詳細は実際には端末固有ですが、
• 誤動作する可能性のある一般的に実装されている機能がいくつかあります。

一般的に実装される機能については、^Nおよび^O（有効化/無効化）によってアクティブ化されるVT100スタイルの代替文字セットを参照してください。UTF-8モードを使用する場合、一部の端末ではこれが抑制される場合がありますが、同じ端末は、認識しているエスケープシーケンスで画面（GNU画面、Linuxコンソール、PuTTYについて話す）を破壊する十分な機会を持っています。

たとえば、他のエスケープシーケンスの一部は、ホストからのクエリ（エスケープシーケンス）への端末からの応答に依存しています。ホストが予期しない場合、結果は画面上のゴミになります。

他の場合（たとえば、Linuxコンソール用のハードコードされたエスケープシーケンスを備えたネットワークデバイスで見られる）、他の端末はそれを誤ってコーディングされていると見なし、フリーズしているように見えます。

だから... 1つの端末だけに集中し、迷惑に見えるものを取り除くことができます（たとえば、エディターでの位置決めにマウスを使用する機能を削除することを提案するものもあります）。しかし、それはたった1つの端末です。

あなたがコントロールしていて、コマンドがあなたを台無しにするつもりであると知っているなら、私は通常、より少ないようなもので出力を見るでしょう。

head -n4 /dev/urandom | less

これは通常、ゴミをキャプチャして健全な表現で印刷するようです.qで終了した後、私が覚えている問題はありませんでした。

コマンドなどの出力をteeにパイプします-