- tmux lange genutzt, in letzter Zeit aber zunehmend skeptisch gegenüber der Komplexität und den Grenzen von tmux geworden (Farbkompatibilität, Scrollback, Kopieren mit der Maus, fehlende Protokollunterstützung usw.)
- Zentrale Funktionen von tmux wie Sitzungspersistenz (detach/attach) oder Fenster aufteilen/verwalten lassen sich nicht zwingend nur mit tmux umsetzen
- Mit leichtgewichtigen Tools im Sinne der Unix-Philosophie wie dtach, abduco, shpool kann man sich auf Sitzungsverwaltung konzentrieren und zugleich nativen Scrollback sowie Einfachheit beibehalten
- Besonders mit der Kombination aus
shpool+ ssh lässt sich eine Umgebung aufbauen, in der mehrere Remote-Sitzungen direkt über den Window Manager verwaltet werden und native Funktionen (Benachrichtigungen, Scrollen, Titel usw.) unverändert nutzbar bleiben - Nicht perfekt, aber aus Sicht des Autors konnte tmux vollständig ersetzt werden, mit einem einfachen und wartungsfreundlichen Workflow, der sehr zufriedenstellend ist
Vor- und Nachteile von tmux
- Sitzungserhalt (detach/attach) und Fensterverwaltung (Tabs, Splits) waren bislang der Kern des Workflows mit tmux
- Ohne korrekt gesetztes
TERMentstehen jedoch Probleme bei der Farbdarstellung, und die Interaktion zwischen Terminal und tmux erhöht die Komplexität - Auch beim Scrollbuffer muss man sich an die eigene Arbeitsweise von tmux gewöhnen, und das Kopieren von Bereichen mit der Maus war in Split-Umgebungen umständlich
- Neue Terminal-Funktionen wie das kitty graphics protocol werden nur unzureichend unterstützt; auch experimentelle Protokolle bleiben außen vor
- Weil ein Multiplexer Escape-Codes doppelt interpretiert und zusätzliche Konzepte wie Sitzungen und Fenster einführt, gibt es auch Kritik, dass er die Weiterentwicklung des Terminal-Ökosystems behindert
Alternativen zu tmux erkunden
- Sitzungspersistenz:
- Einfachere Mittel wie
ctrl-z+fg,nohup,disowngibt es zwar, sie sind aber kein vollständiger Ersatz - Es sind verschiedene Tools entstanden, die nur den Sitzungserhalt zum Ziel haben (
dtach, abduco, shpool)- Verbindung zwischen Daemon und Client per fork()- und UNIX-Socket-Kombination
- Anders als tmux ohne virtuelle Splits, dafür mit nativem Scrollback und teils auch Buffer-Wiederherstellung
- In der Praxis wirkten die meisten Alternativen jedoch unausgereift, mit Bugs und Problemen wie nicht funktionierenden Detach-Tastenkombinationen innerhalb von
nvim - Nur shpool war in Sachen detach/attach-Befehle und Keymap-Anpassung wirklich ausgereift
- Einfachere Mittel wie
- Fensterverwaltung:
- Lokal übernimmt der Window Manager das Aufteilen und Anordnen
- Auch in Remote-Umgebungen (SSH) lassen sich mit ssh_config und shpool mehrere Sitzungen dauerhaft in getrennten Fenstern halten
- In Kombination mit autossh bleibt die Sitzung auch bei Netzunterbrechungen erhalten
Neuer Workflow
- Persönlich werden ghostty (Laptop) und sway+foot (privater PC) für die Fensterverwaltung genutzt. Die Server laufen als headless VMs auf Basis von Proxmox, mit dauerhaft verfügbarer SSH-Entwicklungsumgebung
- Mehrere shpool-Sitzungen werden über ssh-Kurzbefehle automatisch verbunden und lokal im Window Manager unabhängig voneinander gesteuert
- In
ssh_configwird für jeden Host das automatische Attach an die jeweilige shpool-Sitzung eingerichtet - Pro Terminal sind getrennte Sitzungen für IRC, dotfiles-Verwaltung, separate neovim-Umgebungen usw. möglich
- In
- Native Funktionen wie Scrollen, Benachrichtigungen und Terminal-Titel, die tmux nur instabil unterstützte, funktionieren dadurch sogar natürlicher
- Nachteile gibt es ebenfalls: verzögerte Wiederherstellung des Terminalzustands beim erneuten Verbinden mit vim und Resize-Probleme bei Nutzung von
nvim- Kein Multiplayer-Support (Sitzungskonflikte, wenn autossh gleichzeitig von mehreren Clients aus läuft)
- Dennoch wurde tmux aus persönlicher Sicht vollständig ersetzt
Fazit
- Nicht völlig identisch, aber der Wechsel zu einem einfachen und flexiblen Workflow für Sitzungsverwaltung jenseits der Komplexität und Grenzen von tmux ist möglich
- Je nach eigenem Workflow lohnt es sich, Alternativen wie shpool in Betracht zu ziehen
7 Kommentare
Heutzutage lässt man sich so etwas wie
tmuxeinfach mit KI generieren und benutzt es dann. Mit Xterm.js + React + Electron kann man in 3–4 Stunden locker 100 solche Dinge raushauen, sie bei Bedarf in Echtzeit anpassen und benutzen – ein bisschen wie Shabu-Shabu? Man wirft einfach das rein, worauf man Lust hat, und packt den Source-Code ordentlich voll damit.Ich nutze es ganz bequem mit wezterm.
Screen ist das Beste!
cargo install shpool… ich bleibe einfach bei tmux … für jedes OS müssen andere Pakete vorhanden sein!Es gibt einen herausragenden Newcomer namens Zellij. Sehr empfehlenswert.
Zellij – ein Terminal für Entwickler & Ops
Das hatte ich wohl auch schon vor ziemlich langer Zeit gepostet, haha
Hacker-News-Kommentare
Dieser Artikel richtet sich zwar an Linux-on-the-Desktop-Nutzer, aber ich möchte betonen, dass tmux erst richtig glänzt, wenn man es auf einem MacBook mit iTerm2 verwendet
Dank der tmux-Integration von iTerm2 fügt sich tmux in meinen Workflow vollkommen natürlich ein
Wenn man
~/.ssh/configwie unten einrichtet, kann man auch nach dem erneuten Einschalten des MacBooks oder einem Netzwerkwechsel jederzeit per ssh tmux einfach auf den entfernten Entwicklungsserver zugreifenDank der Integration von iTerm2 und tmux verhalten sich entfernte tmux-Tabs und Scroll-Buffer fast wie lokale Tabs, und eigentlich muss man nicht einmal tmux-Befehle kennen, um es zu nutzen
Ich nutze Linux auf all meinen privaten Geräten und arbeite meist auf einem MacBook; tmux ist wirklich nützlich, weil es plattformunabhängig dieselbe Umgebung reproduziert
Unter Linux verwende ich Alacritty, aber auf macOS funktioniert wegen passender Einstellungen oder Unterschieden bei Fenstern/Scrolling immer irgendetwas nicht sofort
Ich möchte keine Zeit auf diese OS-Unterschiede verwenden, daher ist die Kombination aus tmux und iTerm2 gut, weil sie mir eine nahezu identische Erfahrung wie unter Linux bietet
Dass der Scrollback innerhalb der Sitzung vollständig getrennt bereitgestellt wird, ist für mich ebenfalls ein Vorteil
Ich denke, die Kritik an tmux ist eher ein Thema für Terminal-Entwickler
Wenn der Support unzureichend ist, wechselt man eben einfach zu einem Terminal mit besserer Unterstützung
Ich nutze die Kombination aus mosh und screen
Selbst wenn der Server neu startet, kann ich die Sitzung wiederherstellen, und auch bei einem Netzwerkwechsel wird die Sitzung nicht unterbrochen
Siehe auch: Immortal SSH Sessions
Ich habe tmux dutzende Male ausprobiert, aber es hat mir nie besonders gefallen, daher bin ich immer wieder zu screen zurückgekehrt
Aber dieser Tipp macht mir Lust, es noch einmal zu versuchen
In der Kombination aus vim, tmux und iTerm2 bin ich oft auf Probleme mit Farben und Schriftarten gestoßen, sodass ich tmux lokal schließlich aufgegeben habe
Es hat Updates überstanden, und der Gewinn durch Sitzungsfortbestand war für mich nicht besonders groß
Wenn ich nur die Schriftprobleme lösen könnte, wäre ich bereit, es erneut zu versuchen, aber im Moment fehlt mir die Zeit
Ich frage mich, ob es unter den Linux-Terminals eines gibt, das wie iTerm2 Integrationsfunktionen für tmux bietet
Ich nutze immer noch GNU Screen, wäre aber bereit, tmux noch einmal auszuprobieren
Beim Lesen dieses Blogposts ist mir wieder klar geworden, warum ich tmux benutze
Wenn ich sehe, wie viel Arbeit Leute investieren müssen, um einen tmux-ähnlichen Workflow nachzubauen, ist es einfach viel sinnvoller, direkt tmux zu verwenden
Manchmal ist Copy-and-Paste etwas umständlich, aber das stört mich kaum
Die Kritik, ein „Multiplexer verursache unnötigen Overhead“, muss einen nicht interessieren, solange man nicht den Codebestand pflegt
Das Copy-and-Paste-Problem ist kein exklusives Problem von tmux
Es kann bei allen Anwendungen auftreten, die wie vim das gesamte Terminal selbst zeichnen
Mit der Terminal-Escape-Sequenz OSC52 lässt sich das Problem leicht lösen
Mit dem einfachen Python-Skript unten kann man zum Beispiel auch grep-Ergebnisse direkt in die System-Zwischenablage schicken
tmux und nvim unterstützen OSC52 bereits, und man kann es auch andernorts leicht einsetzen
Nur nebenbei: Ich habe einmal einen PR für tmux eingereicht, und mir hat gefallen, wie gut der Maintainer Nick Marriott kommuniziert hat
Der Code ist sauber organisiert, und tmux ist dadurch besser geworden
Ich bin müde von Diskussionen, die scheinbar Probleme konstruieren, wo keine sind
Die Gründe des Autors überzeugen mich nicht, und sogar seine „über 7 Jahre Erfahrung mit tmux“ wirken auf mich fragwürdig
Ich habe Tmux erst vor ein paar Wochen kennengelernt und war fasziniert von den Skriptmöglichkeiten, programmatisch Tasteneingaben an bestimmte Panes zu senden
Inspiriert von einem japanischen Forum habe ich mich gefragt, ob Claude Code (im Folgenden CC) direkt mit CLI-Skripten interagieren könnte, die Benutzereingaben benötigen, und ich habe bestätigt, dass sich das mit Tmux umsetzen lässt
Deshalb habe ich ein kleines Tool namens claude-code-tools gebaut, mit dem CLI-Agenten wie CC Tmux-Panes erzeugen, darin Skripte ausführen und sogar in Echtzeit interagieren können
Es ist gewissermaßen eine Terminal-Version von Playwright oder Puppeteer
claude-code-tools GitHub-Link
Auf diese Weise kann CC CLI-Skripte mit Interaktion automatisch testen, in einem anderen Pane eine UI anzeigen, mit Puppeteer MCP im Browser testen, nach Aktivierung des Debuggers Breakpoints setzen, Multi-Agent-Verknüpfungen bauen und vieles mehr
Ich frage mich, ob alternative Tools zu tmux eine solche Erweiterbarkeit ebenfalls umsetzen können
Nur zur Info: Auch screen kann mit dem Befehl „stuff“ programmatisch Tasteneingaben an ein Pane senden
Mit diesem Ansatz kann Claude Code verschiedene CC-Instanzen wie Gemini CLI oder OpenCode im interaktiven Modus steuern
Damit sind Integrationen möglich, die sich von klassischen Subagenten unterscheiden
Ich frage mich, ob ein tmux-CLI-Wrapper tatsächlich hilft, die Ergebnisse zu verbessern
Bei mir funktioniert es gut, Claude einfach bestehende tmux-Befehle verwenden zu lassen, daher lasse ich alle Befehle direkt in einer tmux-Sitzung laufen, ohne dafür Bash separat zu nutzen
Wenn man so etwas auf Terminal-Ebene einfacher machen möchte, ist auch die Remote-Control-Funktion von Kitty großartig
Einführung in Kitty Remote Control
Ein Terminal ist im Grunde nur ein Dateideskriptor, und ähnliche Tools wie script(1), expect(1) oder chat(8) gibt es schon seit den 80ern
Man braucht nicht zwingend tmux
Dass Farben usw. in tmux nicht korrekt dargestellt werden, wenn TERM nicht richtig gesetzt ist, ist genau dasselbe Problem, das auch bei allen Terminal-Emulatoren/Programmen auftritt
Auf Unix- und Linux-Systemen sind die Konzepte TERM und terminfo/termcap selbst grundlegend, daher ist eine korrekte Konfiguration zwingend erforderlich
Das ist kein tmux-spezifisches Problem
Trotzdem ist es schade, dass der Autor die Schuld tmux zuschiebt
Auch bei den Scroll-Problemen ist fraglich, ob sie wirklich tmux selbst anzulasten sind; tmux verwendet den alternate screen buffer, der eingeführt wurde, um die Viewport-Basislinie klar festzulegen und Cursorbewegungen zu erleichtern
Die meisten modernen Terminals erlauben lokales Scrollen auch im Alternate-Screen-Zustand, weshalb diese Eigenschaft nicht mehr sauber eingehalten wird
Die meisten Programme verhalten sich ebenfalls nicht wie beabsichtigt, wenn die Standardkonfiguration nicht korrekt gesetzt ist
Bei tmux ist nur unangenehm, dass nicht sofort ersichtlich wird, warum, aber was die richtige Lösung wäre, ist unklar (zum Beispiel: Standardmäßig 256colors?)
Das stimmt, aber bei tmux kommt eben noch eine zusätzliche Ebene hinzu, auf die man achten muss
Innerhalb von tmux muss man ein tmux-spezifisches TERM verwenden, außerhalb ein TERM, das zum eigenen Terminal passt
Schon ein Blick in die tmux-FAQ zeigt, dass die meisten Anzeigeprobleme auf ein nicht gesetztes TERM zurückgehen
Der Einwand, ein „Multiplexer verursache unnötigen Overhead“, ist für mich eher ein Grund, tmux zu bevorzugen
In einer Situation, in der immer mehr Apps die termcap-Unterstützung aufgeben, sorgt tmux dafür, dass ich Anwendungen weiterhin sogar auf alten Terminals wie meinem VT520 ausführen kann
Es ist mir ziemlich egal, ob irgendein Terminal-Entwickler tmux nicht mag
Letztlich zählt für Nutzer, dass es funktioniert, nicht architektonische Eleganz
Persönlich halte ich alacritty übrigens für besser (auch wenn ich hauptsächlich Konsole nutze)
Ich möchte nur sagen, dass ich neidisch bin, dass du einen VT520 hast
Ich suche schon lange nach einem VT525, aber die Preise sind hoch und die meisten Verkäufer sitzen im Ausland
Ich habe mich immer gefragt, ob nosh realizer auf einem echten VT525 gut funktioniert
Selbst wenn tmux verschwände, könnte man Apps mit subtilen TERM-Inkompatibilitäten auf andere Weise transliterieren
Mein VT420 unterstützt keine Hardware-Flusskontrolle, daher muss ich Software-Flusskontrolle verwenden, und das ist mit heutigen Terminal-Apps leider nicht besonders kompatibel
GNU Screen ist dafür eine hervorragende Lösung und bietet darüber hinaus viele weitere Funktionen
Ich habe tmux viel in modernen Emulatoren verwendet, aber auf alten Terminals scheint diese wichtige Flusskontrollfunktion zu fehlen
Ich stimme zu, dass tmux nützlich ist, um mit Apps umzugehen, die termcap/terminfo nicht unterstützen
Mich würde interessieren, warum du alacritty für besser hältst
Auf alter Hardware startet es langsamer, es fehlen praktische Funktionen wie Tabs, und selbst in Benchmarks liegt es hinter kitty/ghostty/konsole/foot
Gerade deshalb finde ich es interessant, dass es trotzdem Leute gibt, die alacritty aus irgendeinem Grund verwenden
Ich plane weiterhin, tmux zu benutzen
Ich mag es, weil es die Sitzungsverwaltung über mehrere Projekte hinweg und die Wiederherstellung nach einem Neustart einfach macht
Mit mouse copy/paste hatte ich dank tmux-yank überhaupt keine Probleme
Ich nutze seit Jahren dieselbe Umgebung
Mit der send-keys-Funktion von tmux habe ich beim Refactoring meiner Dotfiles eine Automatisierung gebaut, die gleichzeitig in mehreren Panes/Sitzungen Aliasse oder Konfigurationsdateien aktualisiert und nvim neu startet
Diese Erfahrung habe ich in einem Blogpost und Video festgehalten
Ich sehe „you might not need tmux“ ähnlich wie Diskussionen vom Typ „you might not need browser tabs“
Wenn man nur ein oder zwei Terminal-Sitzungen oder Webseiten hat, braucht man es vielleicht nicht, aber sobald es mehr werden, wird die Fensterverwaltung so unbequem, dass man am Ende dieselben Funktionen wieder selbst nachbaut
Heutzutage versuche ich einfach, die Fensterverwaltungsfunktionen meines Window-Managers so gut wie möglich zu nutzen
Anstatt Browser-Tabs, Terminal-Tabs oder tmux zu verwenden, überlasse ich meinem Window-Manager die Anordnung der Fenster, Tab-Verwaltung, Lesezeichen und Ähnliches, und das funktioniert für mich gut
Ich neige inzwischen fast zu der Überzeugung, dass Tab-Verwaltung Sache des Window-Managers und nicht der Anwendungen sein sollte
Mein Window-Manager kann Fenster kacheln oder überlappende Fenster zu Tab-Gruppen zusammenfassen
Diese Tabs funktionieren unabhängig davon, ob es dieselbe Anwendung oder unterschiedliche Anwendungen sind
Browser-Tabs lassen sich leicht in separate Fenster auslagern oder wieder zusammenführen, aber tmux-Tabs sind in dieser Hinsicht weniger flexibel
Mit einem guten Window-Manager kann man Tabs und Fenster frei neu kombinieren
In meiner tmux-Konfiguration gibt es anklickbare Tabs
Die Mehrfensterverwaltung von MS Windows (Alt Tab, Win Tab usw.) ist wirklich hervorragend
Ich unterscheide jedes Terminal über eigene Icons/Hintergrundfarben, und das Betriebssystem selbst nimmt einem bei der Fensterverwaltung viel Arbeit ab
Ich habe auch Mac verwendet, war in diesem Punkt aber nie so zufrieden wie mit Windows
Gerade die Dinge, über die Leute sich bei tmux beschweren, wie Buffer-Scrollback, sind für mich ein Grund, tmux zu benutzen
Mein zweiter Laptop ist ein alter Debian-Rechner nur für Terminal-Nutzung, ohne Maus, sodass Copy-and-Paste nur über tmux möglich ist
Für mich ist tmux unersetzlich
tmux capture-pane - | vim -ist manchmal praktischer als das Scrollrad der MausDie suckless-Fraktion verfolgt beim Terminal-Design den genau gegenteiligen Ansatz und will Funktionen wie tmux bewusst nicht implementieren
Siehe: st.suckless.org/goals
Ich hoffe, Kitty hat Erfolg, weil es die Zukunft der Terminal-Emulatoren prägen könnte
Aber ich kann Kitty nicht für die Arbeit verwenden, und ohne tmux würden Sitzungen, Fensteranordnung, Zustand, Copy-Buffer und Scrollback verloren gehen, daher kann ich unmöglich darauf verzichten
Bis es unter Windows einen passenden Ersatz gibt, werde ich tmux für die Arbeit weiterverwenden, selbst wenn ich daneben Kitty nutze
Am Ende bin ich aber wieder zur Kombination aus tmux und einem normalen Terminal zurückgekehrt
Weil es überall gut funktioniert und ein aus einzelnen Werkzeugen zusammengesetzter Ansatz langlebiger ist, bleibt tmux für mich weiterhin die beste Wahl