tmux対スクリーン

私は GNU Screen の使用を再開しようとしていますが、tmux がより良い代替手段であるという話を時折耳にするようになりました。Screenが提供しているすべての機能（異なるウィンドウでのアクティビティ監視など）に代わるものを本当に提供しているのでしょうか？それぞれの長所と短所は何ですか？

　 307　 Alison R.　 2011-01-06

ベストアンサー

私がscreenよりもtmuxの方が好きな（主な）理由をいくつか紹介します

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

これが私がスクリーンからtmuxに切り替えた理由のいくつかです。スクリーンにメリットがないわけではありませんが、乗り換えてからの失敗は何も思いつきません。有料のオタクによる他の答えは、プロ/コンのより客観的なリストを持っている, 私はクラッシュやそこに言及されているキーストロークを逃したの問題を持っていたことがないことを逸話的に言うだろうが.(これらは OS に依存している可能性があります。私は Linux と FreeBSD でしか使ったことがありません)

192　 qmega　 2011-01-17

(セッションはウィンドウの集合体であり、後で切り離して再接続することができます。ウィンドウは1つ以上のペインを含むことができます。設定の例としては、こちらやこちらを参照してください。)

tmux

Pros
- IDE のように他のペインにキーを送ることができます
- 簡単なキーバインド — 適切な設定で、Vim や Screen からも安心してお使いいただけます
- Vim系やEmacs系のバインディングが組み込まれています
- タイリングウィンドウのマネージャーみたいなレイアウト管理が上手い
- Unicodeは最近の端末ではジャストフィットするようです
- いくつかのターミナルの問題を TERM=tmux で修正しました
Cons
- ~~遅い — 理由はわかりませんが、キーストロークが遅れているように見えます~~
- ~~多重化は、セッション全体の幅と高さを、最小のアタッチされた端末に強制的に移動させます~~
- ~~Mac OS Xで何度もクラッシュして、セッション全体を失っています~~
- ~~アップグレード後のLinuxでは、以前のセッションに再接続できずに失敗しました~~
- ~~コマンドのキーストロークを時々見落とします – ^A ^[ はコピーモードのために数回試行します~~
- ~~~~あるウィンドウから別のウィンドウにペインを移動できない~~ join-paneコマンドで修正~~
- ~~端末の幅変更（ウィンドウのリサイズ）後、行のアンラップ（リフローやリラップ）を行わない~~

~~GNU Screen~~

Pros
非常に安定しています（v1.0は1987年にありました）
いくつかのターミナルの問題を TERM=screen で修正しました
Emacs的なバインディングが組み込まれています
水平ペインの移動や操作が簡単にできます
マルチプレックス時には、接続されているどの端末でもペインのサイズを変更することができます
~~Cons~~
- ~~パッチなしでは垂直方向の分割はできません（Ubuntuを除く）~~ 最近の画面のリリースでは、垂直方向の分割をサポートしています
- ペインの分割は取り外し時に失われます
- Unicodeを動作させるには、少しのコツと決意が必要です
- 複雑で混乱するステータスラインの設定

104　 a paid nerd　 2011-05-04

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

どのプラットフォームでもtmuxをコンパイルしてもらうことはできると思いますが、たまに画面を活用するだけのアクセスがあることもありますが、実際のシステム管理者は絶対に必要ではないソフトを追加したいとは思っていません

20　 Justin　 2015-04-10

2日ほど前からtmuxを使っているので、私の抑えきれない熱意は、まだ迷惑なユースケースを叩くことで和らげられていません

あるプログラムから別のプログラムに移行することで、いつものように成長する苦痛を経験しながら、私はいくつかの肯定的な機能に打ちのめされましたが、私はもう二度と画面には戻らないと信じている機能は、コピー＆ペーストモードのユーティリティです

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

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

13　 William Pursell　 2012-04-19

私は、GNU Screen を tmux に置き換えました。Aaron Toponce が彼の記事 “Connecting To Serial Null Modems With GNU Screen” で指摘しているように、tmux FAQ には次のように書かれています

スクリーンにはシリアルと telnet のサポートが組み込まれていますが、これは肥大化しており、tmux に追加される可能性は低いでしょう

私の典型的なユースケースは、tmuxとtmuxinatorを組み合わせて、マルチペインとマルチウィンドウの開発セッションを作成することです。tmux を学びたいのであれば、ブライアン・P・ホーガン氏の著書である tmux を入手することをお勧めします。生産的なマウスフリーの開発を手に入れることをお勧めします

9　 Matthew Rankin　 2016-01-17

画面ではなかなか得られないtmuxで得られるものは

垂直方向のペイン分割を作成します
マルチプレックスは、リモートとローカルのペアリングに使用します

8　 community wiki　 2011-01-06

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

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

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

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

例えば 2015年現在ペインを「マーク」する機能があります。または、おそらく、より初歩的な解決策は、ステートフルなシェルスクリプトを使用して解決することができます。私は短いスクリプトとキーバインドを実装して「マークされたペイン」メソッドを試してみましたが、何度か動作しましたが、その後Tmuxは”[lost server]”でクラッシュしました。その後、私が何も複雑なことをしようとしなくても、Tmux がクラッシュしているのを発見しました。どうやら少なくとも数年前から一部のユーザーでクラッシュしていたようです。サーバーがクラッシュすることもあれば、CPUを100%使用して反応しなくなることもあります。私はScreenがこれらのどちらかをしているのを見たことがありません

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

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

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

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

OPの質問に対する簡単な答えにはならないと思いますが、私の視点が役に立っていれば幸いです

4　 Metamorphic　 2019-01-16

tmux のメンテナの一人である Thomas Adam も彼は tmux のコードにしか触れていませんが、プロジェクトのメンテナとしてリストアップされています。これはスクリーンよりもtmuxの巨大なプロです

4　 ninrod　 2017-12-15

スクリーンの使い勝手の良さは強みだと思いますが、ウィンドウシステムはtmuxのものと比べると、扱いやすいとは言えません。私は現在、gnu-screenをほとんどの時間使っていて、その結果、スクリーンウィンドウの代わりにターミナルタブをたくさん持っていると言わざるを得ません

@Jed Schneiderです。Ctrl+Aで垂直ペイン分割を取得し、|(垂直バー)で取得することができます

3　 TafT　 2012-06-21