Ich bin gerade dabei, wieder mit GNU Screen zu arbeiten, aber ich habe gehört, dass Leute gelegentlich tmux als bessere Alternative erwähnen. Bietet es wirklich eine Alternative zu all den Funktionen, die Screen bietet, wie z.B. die Aktivitätsüberwachung in verschiedenen Fenstern usw.? Was sind die Vor- und Nachteile von jedem?
Einige der (Haupt-)Gründe, warum ich tmux gegenüber screen bevorzuge:
tmux ausführen können, kann auch von einer Shell mit tmux command [args] ausgeführt werden. Dies macht es sehr einfach, Skripte zu erstellen und auch komplexe Befehle auszuführen. screen den Titel basierend auf dem ersten Wort des Befehls setzt und eine Shell-Konfiguration benötigt, um selbst das in einem Shell-Fenster zu tun, verfolgt tmux, welche Prozesse tatsächlich in jedem Fenster laufen, und aktualisiert den Titel entsprechend. Auf diese Weise erhalten Sie eine dynamische Umbenennung mit jeder Shell und ohne Konfiguration. Ein Beispiel: Nehmen wir an, Sie verwenden die Z-Shell; der Name des Fensters wäre dann “zsh”. Nehmen wir nun an, Sie wollen eine Konfigurationsdatei bearbeiten, also geben Sie sudo emacs /etc/somefile ein. Während sudo nach Ihrem Passwort fragt, wird der Name des Fensters “sudo” sein, aber sobald Sie das getan haben und sudo startet, wird der Titel “emacs” sein. Wenn Sie damit fertig sind und emacs beenden, ändert sich der Titel wieder in “zsh”. Das ist ziemlich nützlich, um den Überblick über die Fenster zu behalten, und es kann auch in bestimmten Situationen besonders nützlich sein, z. B. wenn Sie einen lang laufenden Prozess in einem anderen Fenster haben, der Sie gelegentlich mit emacs zur Eingabe auffordert; der Fenstername würde sich in “dialog” ändern, wenn das passiert, damit Sie wissen, dass Sie zu diesem Fenster wechseln und etwas tun müssen. dialog selbst viel mehr mit Sitzungen machen. Sie können einfach umschalten, umbenennen usw. und Sie können Fenster zwischen Sitzungen verschieben und gemeinsam nutzen. Es hat auch ein anderes Modell, bei dem jeder Benutzer einen Server hat, der seine Sitzungen kontrolliert und mit dem sich der Client verbindet. Der Nachteil dabei ist, dass man alles verliert, wenn der Server abstürzt; bei mir ist der Server allerdings noch nie abgestürzt. tmux scheint aktiver entwickelt zu werden. Es gibt ziemlich häufig Updates, und Sie können einen Fehlerbericht oder eine Funktionsanfrage gemäß dieser FAQ einreichen und erhalten innerhalb weniger Tage eine Antwort. Das sind nur die großen Dinge, die einem sofort in den Sinn kommen. Es gibt auch noch andere kleine Dinge, und ich bin sicher, dass ich einige Dinge vergessen habe. Es lohnt sich aber auf jeden Fall, tmux einmal auszuprobieren.
(Sessions sind Sammlungen von Fenstern, die abgetrennt und später wieder angehängt werden können. Fenster können ein oder mehrere Panes enthalten. Beispiele für Konfigurationen finden Sie unter hier und hier .)
TERM=tmux behoben join-pane TERM=screen behoben Ein Pro für screen: es ist so ziemlich out-of-the-box auf Linux und Solaris verfügbar. Wenn Sie zwischen den Plattformen hin- und herwechseln müssen, ist es schön, nicht den mentalen Kontextwechsel zu haben.
Ich bin mir sicher, dass man tmux auf jeder Plattform kompiliert bekommen kann, aber manchmal hat man gerade genug Zugriff, um screen zu nutzen, aber die eigentlichen Systemadministratoren wollen nicht wirklich irgendeine Software hinzufügen, die nicht absolut notwendig ist.
Ich benutze tmux jetzt seit etwa 2 Tagen, so dass meine ungezügelte Begeisterung für das Programm noch nicht durch das Auftreten lästiger Anwendungsfälle gedämpft wurde.
Während ich die üblichen Wachstumsschmerzen des Übergangs von einem Programm zum anderen durchmachte, fielen mir mehrere positive Eigenschaften auf, aber die Eigenschaft, die mich glauben lässt, dass ich nie wieder zum Bildschirm zurückkehren werde, ist die Nützlichkeit des Copy-n-Paste-Modus.
In screen kann man nicht in den Kopiermodus gehen, im Puffer zurückblättern und dann zu einem anderen Fenster gehen.
In tmux können Sie mehrere Fenster gleichzeitig im Kopiermodus haben, wobei der Puffer an verschiedene Positionen zurückgescrollt wird. Außerdem gibt es mehrere Kopierpuffer. Und Sie müssen die Quelle nicht patchen, um die fFtT-Cursorbewegung zu erhalten.
Die Dinge, die ich aus tmux herausbekomme, die ich in screen nicht so einfach bekomme, sind:
Ich habe GNU Screen durch tmux in jedem Anwendungsfall ersetzt, außer in einem - wenn ich ein HyperTerminal -Äquivalent brauche, um eine Verbindung zu seriellen Schnittstellen herzustellen. Wie Aaron Toponce in seinem Artikel “Connecting To Serial Null Modems With GNU Screen” anmerkt, heißt es in der tmux FAQ :
Screen hat eingebaute serielle und Telnet-Unterstützung; das ist Bloat und wird wahrscheinlich nicht zu tmux hinzugefügt werden.
Mein typischer tmux Anwendungsfall ist die Erstellung von Multi-Pane- und Multi-Window-Entwicklungssitzungen in Kombination mit tmuxinator . Wenn Sie tmux lernen wollen, empfehle ich Ihnen das Buch von Brian P. Hogan, tmux: Productive Mouse-Free Development .
Ich benutze Screen schon seit langem, aber ich verwende eine Version, die ich 2002 modifiziert habe. Hauptsächlich, weil ich in der Lage sein wollte, die “next/prev”-Navigationsreihenfolge der Reihenfolge anzupassen, in der neue Fenster erstellt wurden, ähnlich wie bei einem Kachel-Fenstermanager wie i3 oder Ion . Das Standardverhalten des Bildschirms ist, dass “next” und “prev” nach der Fensternummer gehen, so dass normalerweise ein “neues” Fenster (das die kleinste verfügbare Nummer nimmt) an einer anderen Stelle als das “nächste” Fenster liegt - verwirrend, wenn man sich die Nummern nicht merken kann. Mein bevorzugtes Verhalten wurde inzwischen in Tmux implementiert als ein Flag zum new-window-Befehl in 2010 , und die renumber-windows-Option in 2012 . Mein Screen-Patch, den ich versucht habe, so akzeptabel wie möglich zu machen, einschließlich Ergänzungen der Dokumentation und so weiter, hat im Juli 2002 keine Diskussion auf der Screen-Liste ausgelöst (damals “screen@informatik.uni-erlangen.de”, kann keine Archive finden). Tatsächlich wurde es nicht einmal zur Kenntnis genommen, selbst als ich es ein Jahr später erneut schickte.
Seit 2002 habe ich meinen Patch ein paar Mal “rebasiert”, um ihn auf neuere Versionen von Screen anzuwenden. Als ich jedoch zu Version 4.3 (2015) kam, bemerkte ich eine undokumentierte Änderung, die eine meiner Anwendungen von Screen kaputt machte - nämlich dass ‘stuff’ nun Umgebungsvariablen interpoliert . Ich brauchte diese Funktion nicht, und ich konnte nicht herausfinden, wie ich das Argument für ‘stuff’ einfach entschlüsseln konnte (so dass ich Text mit Dollarzeichen senden konnte), also habe ich einfach Version 4.0 (von 2004) weiter verwendet.
Ich verwende ‘stuff’ von Screen (‘send-keys’ in Tmux) in einer Emacs-Funktion, die den Inhalt der aktuellen Emacs-Region an eine bestimmte Fensternummer sendet. Auf diese Weise kann ich, wenn ich Code in einer Skriptsprache schreibe, einen Interpreter öffnen, dem Interpreter-Fenster eine spezielle Nummer geben, und dann kann ich mit dieser Emacs-Bindung Codezeilen aus meinem Editor-Fenster direkt an das Interpreter-Fenster senden. Es ist hacky, aber ich mag es besser als die reine Emacs-Lösung , da ich auch mit dem Interpreter in seinem Screen-Fenster mit Standard-Tastenanschlägen interagieren kann. Es ist ein bisschen wie eine GUI-IDE, aber ich muss nicht die Maus benutzen oder auf einen blinkenden Cursor starren.
Eine weitere Funktion, die ich in meinem Patch implementiert habe, ist die Möglichkeit, ein Fenster zu “markieren” und dann das markierte Fenster so zu positionieren, dass es nach dem aktuellen Fenster “das nächste” ist. Für mich ist dies ein viel natürlicherer Weg, Fenster neu zu ordnen als eine neue Nummerierung; es ist wie das Kopieren/Einfügen-Paradigma oder “Drag-and-Drop”. (Ich habe kürzlich herausgefunden, wie man das auch in i3 machen kann.)
Es sollte möglich sein, dasselbe in Tmux zu tun, zum Beispiel ab 2015 gibt es eine Möglichkeit, ein Fenster zu “markieren”. Oder vielleicht könnte eine elementarere Lösung mit zustandsabhängigen Shell-Skripten erarbeitet werden. Ich habe ein kurzes Skript und Keybindings implementiert, um die “marked pane”-Methode auszuprobieren, und es hat ein paar Mal funktioniert, aber dann ist Tmux mit “[lost server]” abgestürzt. Dann stürzte Tmux auch ab, ohne dass ich irgendetwas Kompliziertes versucht habe. Anscheinend stürzt es für einige Benutzer schon seit mindestens ein paar Jahren ab. Manchmal stürzt der Server ab, manchmal fängt er an, 100 % der CPU zu verbrauchen und wird reaktionslos. Ich habe noch nie gesehen, dass Screen eines von beidem macht.
Theoretisch ist Tmux Screen in mehrfacher Hinsicht überlegen. Es hat eine viel bessere Skriptfähigkeit, was bedeutet, dass Sie Dinge wie die Abfrage der Liste der Fenster in der aktuellen Sitzung von der Kommandozeile aus tun können, was mit Screen unmöglich ist. Zum Beispiel hat Screen 2015 einen Befehl zum “Sortieren von Fenstern nach Titel” hinzugefügt. Ich bin mir nicht sicher, wann ein solcher spezialisierter Befehl nützlich wäre, aber diese und praktischere Variationen (z. B. Fenster nach CPU-Auslastung sortieren) könnten relativ einfach von einem Shell-Skript in Tmux erledigt werden. Mir scheint es schwierig, so etwas Kreatives in Screen zu machen, zumindest ohne den C-Code zu modifizieren.
Wie schon von anderen Postern erwähnt, hat Tmux ein Single-Server-Modell, was ich als den Hauptnachteil sehe, besonders wenn der Server abstürzt. Es ist möglich, dies zu umgehen, indem man einen separaten Socket für jede “Sitzung” angibt. Trotzdem bevorzuge ich Screen’s Ein-Server-pro-Sitzung-Standard, der etwas eleganter erscheint.
Die Arbeit mit dem Screen-Code war für mich damals im Jahr 2002 lehrreich und unterhaltsam. Seltsamerweise hat Tmux trotz all seiner zusätzlichen Funktionen etwa 25% weniger Codezeilen als Screen (30k gegenüber 40k). Mir ist aufgefallen, dass Tmux viele Baum- und Listendatenstrukturen verwendet, die für mich etwas schwierig zu verstehen waren. Screen schien Arrays zu bevorzugen.
So wie ich es verstehe, gibt es, weil die Unix-Terminalschnittstelle so stabil ist, wenig Notwendigkeit für den Code von Screen oder Tmux, sich an Änderungen im zugrunde liegenden Betriebssystem anzupassen. Diese Programme haben keine wirklichen Sicherheits-Updates wie Web-Browser oder Web-Server oder sogar die Shell. Ich habe keine Probleme beim Betrieb meiner benutzerdefinierten Version von Screen bemerkt, die zuletzt 2004 aktualisiert wurde (außer dass ich einige Konfigurationsdateien hinzufügen musste, um zu verhindern, dass Systemd den Socket löscht; diese Dateien sind in der Regel ohnehin Teil des Distributionspakets). Vielleicht könnte ich die Probleme, die ich in Tmux hatte, einfach umgehen, indem ich eine Tmux-Version von vor dem Absturz laufen lasse. Natürlich ist es für neue Benutzer nicht sehr gut, wenn genug Benutzer dies tun, da es bedeutet, dass weniger Experten nach Fehlern in den letzten offiziellen Versionen dieser Programme suchen werden. Allerdings ist es schwer, mich zu motivieren, auf ein Produkt umzusteigen, das für mich instabil ist (aktuelles Tmux) oder dem bestimmte Funktionen fehlen, die ich haben möchte (Standard Screen).
Ich weiß, dass dies keine einfache Antwort auf die Frage des OPs ist, aber ich hoffe, dass meine Sichtweise nützlich war.
Ich würde sagen, dass die Verfügbarkeit von Screen seine Stärke ist, aber sein Fenstersystem ist nicht so einfach zu handhaben wie das von tmux . Ich muss sagen, dass ich derzeit die meiste Zeit gnu-screen verwende und als Ergebnis viele Terminal-Tabs anstelle von Screen-Fenstern habe.
@Jed Schneider: Sie können vertikale Fensteraufteilungen mitStrg+A und dann | (vertikaler Balken) erreichen.