Ich war lange Zeit ein starker Benutzer von Screen, verwende jedoch eine Version, die ich bereits 2002 geändert habe. Hauptsächlich, weil ich wollte, dass das Fenster "next / prev" (Nächste / Vorherige) mit der Reihenfolge übereinstimmt, in der es neu ist Fenster wurden erstellt, ähnlich wie bei einem Kachelfenster-Manager wie i3 oder Ion . Das Standardverhalten des Bildschirms ist, dass 'next' und 'prev' nach Fensternummer angezeigt werden, sodass sich normalerweise ein 'neues' Fenster (das die kleinste verfügbare Nummer aufnimmt) an einer anderen Stelle befindet als das 'next' Fenster - verwirrend, wenn Sie keine ' Ich erinnere mich nicht an die Zahlen. Mein bevorzugtes Verhalten wurde seitdem in Tmux als Flag für den Befehl new-window im Jahr 2010 und die Option renumber -windows im Jahr 2012 implementiert. Mein Screen-Patch, den ich so akzeptabel wie möglich zu gestalten versuchte, einschließlich der Hinzufügung von Dokumentation usw., löste im Juli 2002 keine Diskussion auf der Screen-Liste aus (dann "screen@informatik.uni-erlangen.de") Archive suchen). Tatsächlich wurde es nicht einmal zur Kenntnis genommen, selbst als ich es ein Jahr später erneut sandte.
Seit 2002 habe ich meinen Patch ein paarmal "umbasiert", um ihn auf neuere Versionen von Screen anzuwenden. Als ich jedoch zu Version 4.3 (2015) kam, bemerkte ich eine undokumentierte Änderung, die einen meiner Verwendungszwecke des Bildschirms unterbrach - nämlich, dass "Zeug" jetzt Umgebungsvariablen interpoliert . Ich brauchte diese Funktion nicht und konnte nicht herausfinden, wie ich mich dem Argument „stopfen“ (damit ich Text mit Dollarzeichen senden konnte) leicht entziehen konnte. Deshalb verwendete ich weiterhin Version 4.0 (ab 2004).
Ich verwende Screen's 'stuff' ('send-keys' in Tmux) in einer Emacs-Funktion, die den Inhalt der aktuellen Emacs-Region an eine bestimmte Fensternummer sendet. Wenn ich Code in einer Skriptsprache schreibe, öffne ich einen Interpreter, gebe dem Interpreterfenster eine spezielle Nummer und kann dann mit dieser Emacs-Bindung Codezeilen aus meinem Editorfenster direkt an das Interpreterfenster senden. Es ist hackig, aber ich mag es besser als die reine Emacs-Lösung , da ich auch mit dem Interpreter in seinem Bildschirmfenster über Standardtasten interagieren kann. Es ist ein bisschen wie eine GUI-IDE, aber ich muss weder die Maus benutzen noch auf einen blinkenden Cursor starren.
Ein weiteres Feature, das ich in meinem Patch implementiert habe, ist die Möglichkeit, ein Fenster "zu markieren" und das markierte Fenster dann so zu positionieren, dass es nach dem aktuellen "als nächstes" angezeigt wird. Für mich ist dies eine viel natürlichere Art, Fenster neu zu ordnen, als sie neu zu nummerieren. Es ist wie das Kopieren / Einfügen-Paradigma oder "Drag-and-Drop". (Ich habe kürzlich herausgefunden, wie das auch in i3 geht .)
Dasselbe sollte in Tmux möglich sein, zum Beispiel gibt es ab 2015 eine Möglichkeit, eine Scheibe zu "markieren". Oder vielleicht könnte eine elementarere Lösung mit Stateful-Shell-Skripten erarbeitet werden. Ich habe ein kurzes Skript und Tastenkombinationen implementiert, um die Methode "markierter Bereich" auszuprobieren, und es hat ein paar Mal funktioniert, aber dann ist Tmux mit "[lost server]" abgestürzt. Dann fand ich, dass Tmux abstürzte, ohne dass ich etwas Kompliziertes tun musste. Anscheinend ist es für einige Benutzer seit mindestens ein paar Jahren abgestürzt . Manchmal stürzt der Server ab, manchmal nutzt er 100% der CPU und reagiert nicht mehr. Ich habe noch nie gesehen, dass Screen eines von beiden macht.
Theoretisch ist Tmux Screen in mehrfacher Hinsicht überlegen. Die Skriptfähigkeit ist viel besser, dh Sie können beispielsweise die Liste der Fenster in der aktuellen Sitzung über die Befehlszeile abfragen, was mit Screen nicht möglich ist. Beispielsweise hat Screen im Jahr 2015 den Befehl "Fenster nach Titel sortieren" hinzugefügt . Ich bin mir nicht sicher, wann solch ein spezialisierter Befehl nützlich sein würde, aber diese und praktischere Variationen (z. B. Sortieren von Fenstern nach CPU-Auslastung) können relativ einfach über ein Shell-Skript in Tmux ausgeführt werden. Mir scheint es schwierig, etwas so Kreatives in Screen zu machen, zumindest ohne den C-Code zu verändern.
Wie bereits erwähnt, hat Tmux ein Einzelservermodell, das ich als Hauptnachteil betrachte, insbesondere wenn der Server abstürzt. Sie können dies umgehen, indem Sie für jede "Sitzung" einen eigenen Socket angeben. Trotzdem bevorzuge ich die Standardeinstellung von Screen für einen Server pro Sitzung, die etwas eleganter zu sein scheint.
Die Arbeit mit dem Screen-Code im Jahr 2002 war lehrreich und hat mir Spaß gemacht. Seltsamerweise hat Tmux trotz all seiner zusätzlichen Funktionen etwa 25% weniger Codezeilen als Screen (30k vs. 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.
Soweit ich weiß, muss der Screen- oder Tmux-Code aufgrund der Stabilität der Unix-Terminalschnittstelle nur wenig an Änderungen des zugrunde liegenden Betriebssystems angepasst werden. Diese Programme verfügen nicht wirklich über Sicherheitsupdates wie Webbrowser oder Webserver oder sogar die Shell. Ich habe keine Probleme beim Ausführen meiner benutzerdefinierten Version von Screen bemerkt, die zuletzt im Jahr 2004 aktualisiert wurde (außer, dass einige Konfigurationsdateien hinzugefügt werden müssen, um zu verhindern, dass Systemd den Socket löscht; Diese Dateien sind in der Regel ohnehin Bestandteil des Distributionspakets. Vielleicht könnte ich die Probleme, auf die ich in Tmux gestoßen bin, einfach umgehen, indem ich eine Tmux-Version ausführte, bevor sie abstürzte. Wenn genügend Benutzer dies tun, ist dies natürlich nicht sehr gut für neue Benutzer, da weniger Experten in den neuesten offiziellen Versionen dieser Programme nach Fehlern suchen. Es ist jedoch schwierig, mich zu motivieren, auf ein Produkt umzusteigen, das für mich instabil ist (aktuelles Tmux) oder dem bestimmte Funktionen fehlen (Standard-Bildschirm).
Ich weiß, dass dies keine einfache Antwort auf die Frage des OP ist, aber ich hoffe, dass meine Perspektive nützlich war.