最近tail -f実行されているサーバーのログファイルを実行しながらバグを診断しようとしましたが、誤ってキーボードを打って文字を入力しました。これはログ出力と混在し、どちらがどちらであるかを区別することはできません。私はこのように迷惑なことを何度も経験しました。
だから私の質問はこんな感じです。シェル（またはターミナルまたはそれを実行するすべてのプログラム）がキーボード入力とコマンド出力をあいまいに混ぜるのはなぜですか？
私は当面の問題に対する実際の解決策を要求するものではありません。stty -echoコマンドの実行時とstty echo完了時にシェルを実行する方法を見つけることができます。しかし、このように端末を設計した理由が何なのか知りたいです。実用的な目的はありますか？それとも互換性のために行われたものか、まったく考慮していないものですか？
ベストアンサー1
人々は一般的に自分が入力する内容を見たい（パスワードでない限り） :-)
端末はいつでも入力を受け入れ、アプリケーションが読み取るまでバッファリングします。それだけでなくttyがあるときでも料理モードでは、カーネルは一度に行全体をバッファリングし、基本的な行編集機能をいくつか提供することで、バッファリングされた行全体を削除できます（デフォルトのバインディングCtrlとuバックスペース）。行の入力と編集中に端末Enterから読み取るアプリケーションは、キーが押されるまで何も読みません。
カーネルの tty 機能は、このようなアプリケーションがtail端末から出力を生成するように予約されているかどうか、および時期を知らず、不明です。したがって、どういうわけか…キャンセル（？）できません。この場合、この場合にのみ可能です。
とにかく、端末で他のタスクが実行されていて、シェルがコマンドを読み取る準備ができていないときにシェルの次の行を準備できることは特徴はバグではないため、削除をお勧めしません。あまり役に立たないかもしれませんがtail（それ自体で終了しない）、長期実行中に次のコマンドを事前に入力するかcp（makeたとえば）シェルが一般的なものを取得する前に、Ctrl-hと - を使用してCtrlコマンドを編集することをお勧めします。uティモシマーティンに書くコメント:
（偶然）入力したキーストロークが画面に表示されないことを除いて、
less +F somefile同様の機能を提供することは言及する価値があります。tail -f somefileecho
はい、しかし、lessこれらの文字が反響するのを防ぐだけでなく、食べるだから、その内容を読みたい次のアプリケーションがそれを利用できなくなります！
最後に別の理由があります。
歴史的時代（私の時代以前！）には、ローカルエコー機能を備えたターミナルが一般的でした。つまり、端末（通常はハードウェア上）は、ユーザーがローカルに入力した文字をシリアルラインに送信すると同時にエコーバックします。これは、UNIXシステムへの接続に待ち時間が長い場合でも、ユーザーに迅速なフィードバックを提供するのに役立ちます。300ボードモデム自動Telnetを使用して遅いUNIXシステムでターミナルサーバーにダイヤルアップするトークンリングネットワーク - または何でも）。
ローカルエコーを持つ端末がある場合は、stty -echo常に接続されているUNIXサーバーに存在する必要があります。結果は terminak とほぼ同じです。いいえローカルエコー（最近一般的なエコー）とstty echoアクティブ。したがって、この観点から見ると、タスクstty echoは、実行中のソフトウェアに関係なく、文字を受信するとすぐにエコーして端末でローカルエコーが発生する状況をシミュレートすることです。
（しかし、ローカルエコーのある端末がある場合、パスワードを隠すことはできません。）