tmux vs. screen
私は GNU Screen の使用に戻ろうとしています、しかし私は人々が時々 tmux をより良い代替手段として言及するのを聞いています。それは本当に別のウィンドウでの活動監視などのすべての機能 Screen オファーに代わるものを提供していますか？それぞれの長所と短所は何ですか？
私がtmuxよりscreenを好む（主な）理由のいくつか：
- ステータスバーははるかに使いやすいです。現在のウィンドウ、アクティビティのあるウィンドウなどに異なるテキスト/スタイルを簡単に設定できます。また、ステータスバーの左右に、指定した間隔で実行できるシェルコマンド（デフォルト15秒）などを配置できます。
tmux内で実行できるほとんどすべてのコマンドは、tmux command [args]を使用してシェルから実行できます。これにより、スクリプトを非常に簡単に作成できるようになり、複雑なコマンドを簡単に実行できるようになります。- より正確な自動ウィンドウリネーム。
screenはコマンドの最初のWordに基づいてタイトルを設定し、シェルウィンドウでもそのためにシェル構成を必要としますが、tmuxは各ウィンドウで実際に実行されているプロセスを追跡し、それに従ってタイトルを更新します。このようにして、シェルとゼロ構成で動的な名前変更が可能になります。たとえば、Zシェルを実行しているとしましょう。ウィンドウの名前は "zsh"になります。では、設定ファイルを編集したいので、Sudo emacs /etc/somefileと入力しましょう。 Sudoがあなたのパスワードを要求している間、ウィンドウの名前は "Sudo"になりますが、それをしてSudoがemacsを起動すると、タイトルは "emacs"になります。すべて完了してemacsを終了すると、タイトルは "zsh"に戻ります。これはウィンドウを追跡するのに非常に便利です。また、dialogを使用して入力を求められることがある別のウィンドウで実行時間のかかるプロセスがある場合など、特定の状況では特に便利です。これが起こるとウィンドウ名は "dialog"に変わるので、あなたはそのウィンドウに切り替えて何かをしなければならなかったことを知っているでしょう。 - より良いセッション処理（私見）。
tmux自体の中のセッションでもっと多くのことができます。あなたは簡単に切り替え、名前変更などをすることができますし、セッション間でウィンドウを移動して共有することができます。また、各ユーザーが自分のセッションを制御し、クライアントが接続するサーバーを持つという、異なるモデルもあります。この欠点は、サーバーがクラッシュした場合、すべてが失われることです。私はサーバーがクラッシュしたことは一度もありませんでした。 tmuxはもっと積極的に開発されているようです。かなり頻繁に更新があります、そして このFAQ に従ってバグレポートや機能要求を提出し、数日以内に回答を得ることができます。
それらはすぐに頭に浮かぶの主要なものです。他にも小さなことがありますが、忘れていることもあります。 tmuxを試してみる価値は間違いありません。
（セッションは、ウィンドウの集まりで、後で分離して再接続することができます。ウィンドウには、1つ以上のペインが含まれることがあります。例えば、configsの場合は here と ここ ）
tmux
- 長所
- IDEのように、他のペインにキーを送ることができます
- 簡単なキーバインド - 正しい設定で、VimやScreenから自宅にいるように感じるでしょう
- Vim風とEmacs風のバインディングを内蔵
- タイリングウィンドウマネージャによく似た、優れたレイアウト管理
- Unicodeは現代の端末ではうまく動作するようです
TERM=tmuxで修正された端末の問題
- 短所
遅い - 理由がわからないが、キーストロークが遅れているように見えるこれ以上遅さの問題はありません- 多重化により、セッション全体の幅と高さが最小の接続端末に強制されます
- Mac OS Xで何度もクラッシュし、セッション全体を失った
- アップグレード後にLinuxで失敗しました。古いセッションに再接続できませんでした。
- 時折コマンドキーストロークを逃す - ^A ^[ コピーモードを数回試します。
あるウィンドウから別のウィンドウにペインを移動できませんjoin-paneコマンドで修正- 端末幅の変更（ウィンドウのサイズ変更）後に行が折り返されない（または「リフロー」または「再折り返し」）
GNUスクリーン
- 長所
- 非常に安定しています（v1.0は1987年でした）
TERM=screenで修正された端末の問題- Emacs風のバインディングが組み込まれています
- 水平ペインの移動と制御が簡単
- 多重化時には、接続されている端末はペインのサイズを変更できます
- 短所
- パッチなしで垂直分割はできません（Ubuntuを除く）
- デタッチ時にペイン分割が失われる
- Unicodeを機能させるには、少し巧妙で決心したものが必要です。
- クレイジーステータスラインの設定
スクリーンのためのプロ：それはLinuxとSolarisでほとんどそのまま使用可能です。プラットフォームを切り替える必要があるときは、メンタルコンテキストを切り替えないようにするのがいいでしょう。
私はあなたがどんなプラットフォームでもtmuxをコンパイルすることができると確信しています、しかし時々あなたはスクリーンを利用するためにちょうど十分なアクセスを持っています、しかし実際のシステム管理者は本当に必要でないソフトウェアを加えたくありません。
私は約2日間tmuxを使用してきたので、それに対する私の束縛されない熱意はまだ迷惑な使用例を打つことによって和らげられていません。あるプログラムから別のプログラムに移行するという通常の苦痛を乗り越えている間、私はいくつかの良い機能に悩まされましたが、決して画面に戻らないと思っている機能はコピー＆ペーストモードの有用性です。画面では、コピーモードに入ってバッファ内をスクロールして戻って別のウィンドウに移動することはできません。 tmuxでは、バッファを別の位置にスクロールバックしながら、コピーモードで同時に複数のウィンドウを持つことができます。また、複数のコピーバッファがあります。そして、あなたはfFtTカーソル移動を得るためにソースをパッチする必要はありません。
私がtmuxから抜け出すものは私がスクリーンで簡単には得られない：
- 垂直区画を分割する
- これをリモートとローカルのペアリングに使用します。
1つを除くすべての使用例で、 GNU Screen を tmux に置き換えました。 ハイパーターミナル 相当物が必要な場合シリアルポートに接続します。 Aaron Toponceが彼の記事 「GNU画面を使ったシリアルヌルモデムへの接続」 で述べたように、 tmux FAQ はこう述べています。
screenはシリアルとtelnetをサポートしています。これは膨大であり、tmuxに追加されることはまずありません。
私の典型的な tmux ユースケースは、 tmuxinator と組み合わせてマルチペインおよびマルチウィンドウ開発セッションを作成することです。 tmux を学びたい場合は、Brian P. Hoganの本 を読んでください。tmux：Productive Mouse-Free Development .
私は長い間Screenのヘビーユーザーでしたが、2002年に修正したバージョンを使用しています。主に、ウィンドウの「次/前」ナビゲーション順序を新しい順序と一致させたいと思ったためです。 i や Ion などのタイルウィンドウマネージャーに似たウィンドウが作成されました。標準の画面の動作は、「次」と「前」がウィンドウ番号で移動するため、通常は「新しい」ウィンドウ（利用可能な最小の番号を取得）は「次」ウィンドウ以外の場所に配置されます-そうしないと混乱します数字を覚えておいてください。私の好みの動作は、Tmuxで 2010年のnew-windowコマンドへのフラグ 、および 2012年のrenumber-windowsオプション として実装されました。ドキュメントの追加などを含め、可能な限り受け入れようとした私のスクリーンパッチは、2002年7月にスクリーンリストに関する議論を生成しませんでした（「[email protected]」はできません。アーカイブを見つけます）。実際、1年後にもう一度送ったとしても、それは認められませんでした。
2002年以来、新しいバージョンのScreenに適用するために、パッチを数回「リベース」しています。しかし、バージョン4.3（2015）に到達したとき、画面の使用の1つを壊した文書化されていない変更に気付きました。つまり、 'stuff'は環境変数を補間する です。私はその機能を必要としなかったので、引数を「もの」に簡単にエスケープする方法がわからなかったので（ドル記号を含むテキストを送信できるように）、バージョン4.0（2004年以降）を使い続けました。
現在のEmacsリージョンの内容を特定のウィンドウ番号に送信するEmacs関数で、Screenの「もの」（Tmuxでは「送信キー」）を使用します。そうすることで、スクリプト言語でコードを書いているときにインタープリターを開き、インタープリターウィンドウに特別な番号を付け、このEmacsバインディングを使用してエディターウィンドウからインタープリターウィンドウにコードの行を直接送信できます。それはハックですが、標準のキーストロークを使用して画面ウィンドウでインタプリタと対話することもできるため、 純粋なEmacsソリューション よりも優れています。 GUI IDEに少し似ていますが、マウスを使用したり、点滅するカーソルを見つめたりする必要はありません。
パッチに実装したもう1つの機能は、ウィンドウを「マーク」し、マークしたウィンドウを現在のウィンドウの「次」に再配置する機能です。私にとって、これは番号の付け直しよりもはるかに自然なウィンドウの順序変更です。これは、コピー/貼り付けのパラダイム、または「ドラッグアンドドロップ」のようなものです。 （I 最近i3でこれを行う方法を見つけた も同様。）
Tmuxで同じことを行うことができるはずです。たとえば、 2015年現在 ペインを「マーク」する機能があります。または、おそらく、より基本的なソリューションは、ステートフルシェルスクリプトで解決できます。短いスクリプトとキーバインドを実装して「マークされたペイン」メソッドを試してみましたが、数回機能しましたが、Tmuxが「[lost server]」でクラッシュしました。それから、複雑なことを何も試みなくても、Tmuxがクラッシュすることがわかりました。どうやら 一部のユーザーにとってはクラッシュしている少なくとも数年 。サーバーがクラッシュしたり、CPUの100％を使用し始めて応答しなくなることがあります。 Screenがこれらのいずれかを行うのを見たことがありません。
理論的には、Tmuxはいくつかの点でScreenよりも優れています。スクリプト性がはるかに優れています。つまり、現在のセッションのウィンドウのリストをコマンドラインから照会するなど、Screenでは不可能なことを実行できます。たとえば、2015 Screen 「タイトルでウィンドウを並べ替える」コマンドを追加 。このような特殊なコマンドがいつ役立つかはわかりませんが、Tmuxのシェルスクリプトを使用すれば、この実用的なバリエーション（たとえば、CPU使用率でウィンドウを並べ替える）を比較的簡単に実行できます。私には、少なくともCコードを変更しない限り、Screenでこれほど創造的なことを行うのは難しいように思えます。
他のポスターが言及したように、Tmuxには単一サーバーモデルがあり、これは特にサーバーがクラッシュしている場合の主な欠点です。 「セッション」ごとに個別のソケットを指定することにより、この問題を回避することができます。それでも、私はScreenのセッションごとに1サーバーあたりのデフォルトを好みます。
2002年のScreenコードの操作は、教育的で楽しいものでした。奇妙なことに、すべての追加機能について、TmuxにはScreenよりも約25％少ないコード行があります（30k対40k）。 Tmuxは多くのツリーとリストのデータ構造を使用していることに気付きました。画面は配列を好むようでした。
私が理解しているように、Unixターミナルインターフェイスは非常に安定しているため、基盤となるオペレーティングシステムの変更に対応するためにScreenまたはTmuxコードを使用する必要はほとんどありません。これらのプログラムには、実際にはWebブラウザーやWebサーバー、さらにはシェルなどのセキュリティ更新プログラムはありません。 2004年に最後に更新されたScreenのカスタムバージョンの実行に問題はありません（追加する必要がある場合を除き Systemdがソケットを削除しないようにするためのいくつかの構成ファイル ;これらのファイルは通常ディストリビューションの一部ですとにかくパッケージ）。おそらく、クラッシュを開始する前からTmuxバージョンを実行することで、Tmuxで発生した問題を回避することができました。もちろん、十分なユーザーがこれを行うと、これらのプログラムの最新の公式バージョンでバグを探す専門家が少なくなるため、新規ユーザーにはあまり適していません。ただし、私にとって不安定な製品（最新のTmux）または必要な特定の機能を備えていない製品（標準の画面）に切り替えるように動機付けるのは困難です。
これはOPの質問に対する簡単な答えを提供するものではないことは知っていますが、私の視点が役立ったことを願っています。
Screenの可用性はその強みだと思うが、そのウィンドウシステムは tmux のように扱いが簡単ではない。私は gnu-screen 現時点ではほとんどの時間使用していると言わなければなりません。その結果、スクリーンウィンドウの代わりにたくさんのターミナルタブがあります。
@Jed Schneider：垂直方向のペイン分割は Ctrl+A その後 | （縦線）.
Tmuxのメンテナの一人であるThomas Adamもまた、screenプロジェクトのメンテナとして リストされています 。彼はtmuxコードにしか触れていません。これは画面上のtmuxの巨大なプロです。