![GNU Screen、どのコマンドでもロックアップが発生する](https://rvso.com/image/1259780/GNU%20Screen%E3%80%81%E3%81%A9%E3%81%AE%E3%82%B3%E3%83%9E%E3%83%B3%E3%83%89%E3%81%A7%E3%82%82%E3%83%AD%E3%83%83%E3%82%AF%E3%82%A2%E3%83%83%E3%83%97%E3%81%8C%E7%99%BA%E7%94%9F%E3%81%99%E3%82%8B.png)
私はリモート ボックスに ssh で接続しています。Red Hat だと思いますが、確認方法がわかりません。まだインストールされていないため、ホーム ディレクトリで、screen とそのすべての依存関係をソースからインストールするプロセスを実行しました。
screen を実行すると、問題なく開き、プロンプトが表示されますが、ls、vim、zsh などのコマンドを実行すると、単にフリーズしてしまいます。このことを 6 時間ほど Google で検索していますが、「画面がロック/ハング/フリーズする」(明らかに追加の検索語句を含む) と、無関係な結果が多すぎて、関連するものがないようです。
gnu screen にはコンパイル オプションがあまりありません。助けてくれる人がいる場合、どのような情報を提供すればよいでしょうか?
答え1
奇妙なことに、これは TERM の問題だったようです。私は、zsh を実行している X の外部のターミナルから ssh していました。システムで ssh しようとしたときに、term を vt220 に変更すると、これらの設定で、またはリモート ホストで TERM="linux" を手動で設定すると、画面がロックされます。ただし、X からは、zsh を実行している rxvt-unicode ターミナルから ssh し、リモート ホストの TERM を 'rxvt' に手動で設定してから、画面を起動します。画面は term を "screen.rxvt" に設定し、正常に動作します。
いずれにせよ、今後は X からのみ ssh を実行するつもりです。使用していたボックス (gentoo) で X がまだコンパイル中だったので、ターミナルから実行しました。したがって、これは TERM の問題として解決できると思いますが、他の誰かがこれに遭遇した場合、X 以外で回避策があるかどうかはわかりません。