私がtmuxよりもscreenを好む（主な）理由のいくつか。

• ステータスバーはとても使いやすい。現在のウィンドウやアクティビティのあるウィンドウなど、異なるテキストやスタイルを簡単に設定でき、指定した間隔(デフォルトは 15 秒)で実行できるシェルコマンドなどをステータスバーの左右に配置できます。
• tmux の中で実行できるコマンドのほとんどは、tmux command [args] を使ってシェルから実行できます。これにより、非常に簡単にスクリプト化でき、複雑なコマンドを簡単に実行できるようになります。
• より正確な自動ウィンドウリネーム。screen がコマンドの最初の単語に基づいてタイトルを設定するのに対し、tmux は各ウィンドウで実際にどのようなプロセスが実行されているかを追跡し、それに応じてタイトルを更新します。このようにして、どんなシェルでも動的な名前の変更が可能になり、設定は不要になります。例えば、以下のようになります。例えば、Z シェルを実行しているとします。さて、設定ファイルを編集したいので sudo emacs /etc/somefile と入力します。sudo がパスワードを聞いている間、ウィンドウの名前は “sudo” になりますが、それが終わって sudo が emacs を起動すると、タイトルは “emacs” になります。これが終わってemacsを終了すると、タイトルは “zsh "に戻ります。これはウィンドウを追跡するのに非常に便利です。また、別のウィンドウで長時間実行しているプロセスがある場合に、dialog を使って時々入力を要求してくる場合など、特定の状況では特に便利です。
• より良いセッション処理(IMHO)。tmuxの中では、セッションでできることはもっとたくさんあります。切り替えや名前の変更などが簡単にできますし、セッション間でウィンドウを移動したり共有したりすることができます。また、各ユーザが自分のセッションを制御するサーバを持ち、クライアントが接続するという別のモデルもあります。このモデルの欠点は、サーバーがクラッシュするとすべてを失うことです。
• tmux はより積極的に開発されているようです。かなり頻繁にアップデートが行われていて、 この FAQ に従ったバグレポートや機能リクエスト を提出すれば、数日以内に回答を得ることができます。

これらはすぐに思いつく主なものだけです。他にも小さなこともありますし、忘れていることもあると思います。tmuxを試してみる価値はあると思います。

(Sessions は windows の集合体であり、後で切り離して再接続することができます。Windowsには1つまたは複数のpanesが含まれている場合があります。設定の例としては、こちらとこちらを参照してください。)

tmux

• 長所
• 他のペインにキーを送ることができる、IDE のようなもの
• 簡単なキーバインド – 正しい設定をすれば、Vim や Screen からでもくつろげる
• Vim 的なバインディングと Emacs 的なバインディングが組み込まれている
• 優れたレイアウト管理。タイリングウィンドウマネージャに似ている
• Unicode は最新の端末でも動作するようです
• いくつかの端末の問題は TERM=tmux で修正されています
• 短所
• ~~Slow – 理由は不明ですが、キー入力が遅れているようです
• スローネスの問題はもうありません
• マルチプレックスがセッションの幅と高さ全体を最小の端末に強制的に接続します
• Mac OS X で何度もクラッシュしています。セッション全体を失う
• アップグレード後の Linux で失敗しました。古いセッションに再接続できない
• 時々コマンドキーストロークをミスる
• ^A ^[ コピーモードで数回試行する
• ウィンドウから別のウィンドウにペインを移動できない~ join-pane コマンドで修正
• 端末の幅変更(ウィンドウのサイズ変更)後に行のアンラップ(または “reflow” または “rewrap” )をしない

GNU Screen

• 長所
• 非常に安定している (v1.0 は 1987 年のもの)
• いくつかの端末の問題が TERM=screen で修正されている。 0は1987年のもの)
• いくつかのターミナルの問題が0x6& で修正された
• Emacs的なバインディングが組み込まれている
• 水平方向のペインの移動と制御が簡単
• マルチプレックス時に、どのターミナルでもペインのサイズを変更できる
• 短所
• パッチなしでは垂直方向の分割ができない (Ubuntuを除く)
• ペインの分割が切り離すと失われる
• Unicodeを動作させるためには、ちょっとした工夫と決断が必要
• 狂ったようなステータスラインの設定

画面のためのプロ：それはLinuxとSolaris上でかなりアウトオブボックスで利用可能です。プラットフォーム間を行ったり来たりして切り替えなければならないとき、精神的なコンテキストスイッチがないのはいいことです。

どのプラットフォームでもtmuxをコンパイルしてもらえると思いますが、スクリーンを利用するのに十分なアクセスがあるだけの場合もありますが、実際のシステム管理者は絶対に必要ではないソフトウェアを追加したいとは思っていません。

tmuxを使い始めて2日ほど経ちましたが、まだ私の熱狂的な熱意は、迷惑なユースケースにぶつかることで抑えられていません。

あるプログラムから別のプログラムに移行する際に、いつものように成長する苦痛を経験しながら、いくつかのポジティブな機能に心を打たれましたが、もう二度と画面には戻れないと信じている機能は、コピー＆ペーストモードの有用性です。

screenでは、コピーモードに入ってバッファ内をスクロールしてから別のウィンドウに移動することができません。

tmuxでは、コピーモードに入ってバッファをスクロールバックして別の位置に移動した状態で複数のウィンドウを同時に持つことができます。また、コピーバッファは複数あります。また、ソースにパッチを当てなくてもfFtTカーソルの動きが得られます。

スクリーンではなかなか得られないtmuxから得られるものは以下の通り。

1. 垂直方向のペイン分割を行う
2. リモートとローカルのペアリングに使用する多重化。

私は、シリアルポートに接続するために HyperTerminal と同等のものが必要な場合を除いて、すべてのユースケースで GNU Screen を tmux に置き換えています。Aaron Toponceが彼の記事 “Connecting To Serial Null Modems With GNU Screen” で述べているように、 tmux FAQ には次のように書かれています。

screenにはシリアルとtelnetのサポートが組み込まれています。

私の典型的な使用例は、 tmuxinator と組み合わせて、マルチペインとマルチウィンドウの開発セッションを作成することです。tmux ](https://github.com/tmuxinator/tmuxinator)について学びたい場合は、Brian P. Hogan氏の著書である tmux: Productive Mouse-Free Development を入手することをお勧めします。

tmuxのメンテナの一人であるThomas Adamも リストとしてscreenプロジェクトのメンテナとして参加していますが、彼はtmuxのコードにしか触れていません。これはスクリーンよりもtmuxの方が圧倒的に優れています。

私は長い間 Screen のヘビーユーザーでしたが、2002 年に修正したバージョンを使用しています。主に、 i3 や Ion 標準的なスクリーンの動作は、'next’ と ‘prev’ がウィンドウ番号順に移動するため、通常は ‘new’ ウィンドウ (利用可能な最小の番号を取得する) が ‘next’ ウィンドウとは別の場所に配置されます。私の好みの動作はその後、Tmux に 2010年の new-window コマンドへのフラグ と、2012年の renumber-windows オプション として実装されています。私の Screen パッチは、ドキュメントの追加などを含めて可能な限り受け入れられるようにしようとしたのですが、2002年7月の Screen メーリングリスト (当時は “screen@informatik.uni-erlangen.de” だったのですが、アーカイブが見つかりません) では何の議論もされていませんでした。実際、1年後に再送したときにも、それは認められていませんでした。

2002年以降、私は新しいバージョンの Screen に適用するために、何度かパッチを「リベース」しました。しかし、バージョン 4.3 (2015) になったとき、文書化されていない変更があったことに気付きました。私はその機能を必要としていなかったし、(ドル記号を含むテキストを送信するために) ‘stuff’ の引数を簡単にエスケープする方法がわからなかったので、バージョン 4.0 (2004年以降) を使い続けていました。

私は現在のEmacsリージョンの内容を特定のウィンドウ番号に送るEmacs関数の中でScreenの'stuff'（Tmuxでは'send-keys'）を使っています。そうすることで、スクリプト言語でコードを書いているときにインタープリタを開き、インタープリタのウィンドウに特別な番号を与えて、Emacs のバインディングを使ってエディタのウィンドウから直接インタープリタのウィンドウにコードの行を送ることができるようになります。これはハックな方法ですが、純粋なEmacsソリューションよりも気に入っています。GUI IDEのようなものですが、マウスを使ったり、点滅するカーソルを凝視したりする必要がありません。

私がパッチで実装したもう一つの機能は、ウィンドウを「マーク」して、マークしたウィンドウを現在のウィンドウの後に「次」に配置する機能です。私にとっては、これはリナンバリングよりもずっと自然なウィンドウの並び替え方法です。(私は 最近 i3 でこれを行う方法を発見しました )

Tmux でも同様のことが可能なはずです。あるいは、もっと初歩的な解決策として、ステートフルなシェルスクリプトを使って解決することができるかもしれません。私は短いスクリプトとキーバインドを実装して、"マークされたペイン “メソッドを試してみました。その後、何も複雑なことをしようとしなくても、Tmux がクラッシュしているのを発見しました。どうやら 一部のユーザでは 少なくとも数年前からでクラッシュしていたようです。時々サーバーがクラッシュしたり、CPUを100%使用して反応しなくなったりします。私はScreenがこれらのどちらかをしているのを見たことがありません。

理論的には、Tmux はいくつかの点で Screen より優れています。Tmux ははるかに優れたスクリプト性を持っており、Screen では不可能な、現在のセッションのウィンドウのリストをコマンドラインから照会するようなことができます。例えば、2015 年に Screen "sort windows by title” コマンドを追加 . このような特化したコマンドがいつ役に立つのかはわかりませんが、これやより実用的なバリエーション(CPU使用率によるウィンドウのソートなど)は、Tmuxのシェルスクリプトから比較的簡単に行うことができます。私には、少なくとも C コードを修正せずに、Screen でこれほど独創的なことをするのは難しいと思われます。

他の投稿者が述べているように、Tmux はシングルサーバーモデルを採用しています。各「セッション」ごとに別のソケットを指定することで、これを回避することができます。それでも私は、Screen のデフォルトのワンサーバー/セッションモデルの方が若干エレガントな気がします。

2002 年に Screen のコードを使って仕事をしたことは、私にとって勉強になりましたし、楽しかったです。奇妙なことに、すべての追加機能のために、Tmux のコード行数は Screen よりも約 25%少なくなっています (30k 対 40k)。Tmux は多くのツリーとリストのデータ構造を使用していることに気付きましたが、これは私には理解するのが少し難しかったです。Screenは配列を好むようです。

私が理解しているように、Unix 端末のインターフェイスは非常に安定しているので、Screen や Tmux のコードが、基盤となるオペレーティングシステムの変更に適応する必要性はほとんどありません。これらのプログラムには、ウェブブラウザやウェブサーバ、シェルのようなセキュリティアップデートはありません。2004 年に最後に更新されたカスタムバージョンの Screen を実行しても問題はありません (ただし、Systemd がソケットを削除するのを防ぐために いくつかの設定ファイル を追加する必要があることを除いては)。これらのファイルは通常ディストリビューションパッケージの一部です)。おそらく私は、Tmux がクラッシュし始める前のバージョンを実行することで、Tmux で遭遇した問題を回避することができるでしょう。もちろん、もし十分な数のユーザがこれを行うならば、新しいユーザにとってはあまり良いことではないでしょう。しかし、自分にとって不安定な製品(最新のTmux)や、自分が欲しい機能が欠けている製品(標準のScreen)に乗り換えようと思うと、なかなかモチベーションが上がらない。

これがOPの質問に対する簡単な答えになっていないことは分かっていますが、私の視点がお役に立てたなら幸いです。

スクリーンの利用可能性は強みだと思いますが、ウィンドウシステムは tmux のような扱いやすさではありません。私は現在、ほとんどの時間を gnu-screen を使用しており、その結果、スクリーンウィンドウの代わりにターミナルタブをたくさん使用していると言わざるを得ません。

@Jed Schneider. Ctrl+A と | (垂直バー) で垂直方向のペイン分割ができます。