コマンドの実行中に端末がキーストロークをエコーするのはなぜですか？
最近、実行中のサーバーのログファイルでtail -fを実行していて、誤ってキーボードをぶつけていくつかの文字を入力したときに、バグを診断しようとしました。それらはログの出力と混同され、どちらがどれであるかを判断する方法がありませんでした。私も同じように迷惑なことが何度も起こりましたが、ここの他の多くの人々にも起こったと確信しています。
だから私の質問はこれです：なぜシェル（または端末、またはそれをしているもの）はキーボード入力とコマンド出力をあいまいに混ぜるのですか？
私は当面の問題に対する実際的な解決策を求めていません。コマンドの実行時にシェルをstty -echoで実行し、コマンドの実行が終了するとstty echoを実行する方法を見つけられるかもしれません。しかし、私はこのような端末を設計する背後にある理論的根拠を知りたいです。実用的な目的はありますか？それとも、互換性の理由だけで行われたものですか、それともまったく考慮されていないものですか？
人々は通常、自分が入力しているものを見たいと思っています（パスワードでない限り）:-)
端末はいつでも入力を受け入れ、アプリケーションがそれを読み取るまで入力をバッファリングします。それ以上に、ttyがcookedモードの場合、カーネルは一度に行全体をバッファリングし、殺すことができるいくつかの基本的な行編集機能を提供しますバッファリングされた行全体（デフォルトのバインディング Ctrl-u とバックスペース。行が入力および編集されている間、およびを押すまで Enter、端末から読み取るアプリケーションは何も読み取りません。
カーネルのtty機能は、tailのようなアプリケーションが端末で出力を生成することを計画しているかどうか、またいつ生成するかを認識できないため、どういうわけか...行編集をキャンセル（？）できません。そのような時とその時だけ。
とにかく、他の何かがまだターミナルで実行されていて、シェルがまだそのコマンドを読み取る準備ができていないときにシェルの次の行を準備できることは、機能、バグではないので、削除することはお勧めしません。 tail（それ自体で終了することはありません）にはあまり役に立たないかもしれませんが、長時間実行されるcpまたはmakeの間に次のコマンドを事前に入力します（たとえば） 、さらにそのコマンドを編集する Ctrl-h そして Ctrl-u、シェルがそれを取得する前に、行うのが一般的なことです。 ティモシーマーティン で書いた コメント ：
less +F somefileはtail -f somefileと同様の機能を提供しますが、（誤って）入力されたキーストロークが画面にechoされない点が異なります。
ええ、でもlessはそれらの文字がエコーされるのを防ぐだけでなく、それらを食べるので、次の文字には使用できませんそれらを読みたいアプリケーション！
最後に、もう1つの理由があります。
歴史的な時代（私の時代より前！）には、ローカルエコーを備えた端末が一般的でした。つまり、端末（通常はハードウェア内）は、ローカルで入力した文字をエコーすると同時に、シリアルラインに送信します。これは、UNIXシステムへの接続に多くの遅延があった場合でも、ユーザーに迅速なフィードバックを提供するのに役立ちます（ 0ボーモデム 自動telnetを使用してターミナルサーバーを低速のUNIXシステムにダイヤルアップするa トークンリング ネットワーク—または何でも）。
ローカルエコーを備えた端末がある場合は、接続先のUNIXサーバー上で常にstty -echoが必要です。結果は、ターミナックなしローカルエコー（今日の一般的な種類）およびstty echoが有効になっている場合とほぼ同じです。したがって、その観点から、stty echoの仕事は、実行中のソフトウェアに関係なく、ローカルエコーを備えた端末で何が起こるかをエミュレートして、文字を受信するとすぐにエコーすることです。
（ちなみに、ローカルエコー付きの端末をお持ちの場合、パスワードを隠すことはできません。）
zshを使用して、特定のコマンドに対してttyデバイスローカルechoを無効にする場合は、次の操作を実行できます。
STTY=-echo a-specific-command
zshは（sttyを呼び出すことにより）特定の設定を適用し、コマンドの終了時にそれらを復元します。
もちろん、おそらくttyデバイスから読み取らないアプリケーションに対してのみこれを実行する必要があります。