予想される動作:
出力速度ls /*が非常に高速です。
実際の動作：
$ time ls /*
...
real 0m21.003s
user 0m0.082s
sys 0m0.095s
このコマンドを完了するには21秒かかります。行はゆっくりスクロールします。何かが間違っていた。私はこれを実行しており、screen実行していますxterm。私は問題を解決しようとしましたが、まだ何が起こっているのかわかりませんでした。ところで不思議な点を発見しました。
解決策：
何らかの理由で私が作成したこのスクリプトを実行すると、期待どおりに機能します。http://sprunge.us/zdvZEO
$ fastout
...
$ time ls /*
...
real 0m1.375s
user 0m0.116s
sys 0m0.116s
いくつかのTERMCAPファイル（どんなファイルなのか覚えていません）を操作して偶然にcatこの問題を発見し、ファイル（一部）を端末に送信したときに問題が消えたことがわかりました。何が起こると思いますか？回避策に頼らずに、この問題を適切に解決できますか？
編集1：
デフォルト設定urxvtと同じセッションが接続されている状態でテストされましたscreen。
$ time ls /*
...
real 0m0.281s
user 0m0.051s
sys 0m0.080s
xtermこの観点から、問題は設定に関連しています。
編集2：
これを行うことが私のカスタム設定ではないことを確認するために、xterm次のことを試しました。
$ xrdb -remove
$ /bin/xterm
同じ結果。
おそらくxtermそれは問題ではなく、screen実行に対するGNUの反応にすぎませんかxterm？
まだはっきりしていませんが、何年も慣れてきたにもかかわらず、おそらく設定でこの問題がないだけでなく、ブロック選択もできるものに切り替えますxterm。urxvt
編集3：
.screenrcをに変更すると、
hardstatus alwaysfirstline
ランタイムhardstatus alwayslastline
の問題がなくなることがわかりました（出力は期待どおりに機能します）。両方の設定でうまく機能します。その設定を変更してそのままにすることはできますが、バーが一番上にあることを望みます。xtermscreenurxvtxterm