Ik sta op het punt om GNU Screen weer te gaan gebruiken, maar ik heb mensen af en toe horen spreken over tmux als een beter alternatief. Biedt dit echt een alternatief voor alle mogelijkheden die Screen biedt, zoals het monitoren van activiteiten in verschillende vensters, etc.? Wat zijn de voor- en nadelen van beide?
Enkele van de (belangrijkste) redenen waarom ik de voorkeur geef aan tmux boven screen:
tmux kunt uitvoeren, kun je ook vanuit een shell met tmux command [args] uitvoeren. Dit maakt het zeer eenvoudig scriptbaar, evenals het gemakkelijk maken om complexe commando’s uit te voeren. screen de titel instelt op basis van het eerste woord van het commando, en een shell configuratie nodig heeft om zelfs dat in een shell venster te doen, houdt tmux bij welke processen er daadwerkelijk in elk venster draaien, en werkt de titel dienovereenkomstig bij. Op deze manier krijg je dynamische hernoeming met elke shell en nul configuratie. Bijvoorbeeld: Laten we zeggen dat je Z Shell draait; de naam van het venster zou “zsh” zijn. Laten we zeggen dat je een configuratie bestand wil bewerken, dus typ je sudo emacs /etc/somefile. Terwijl sudo om je wachtwoord vraagt, zal de naam van het venster “sudo” zijn, maar eens je dat gedaan hebt en sudo start, zal de titel “emacs” zijn. Als je klaar bent en je sluit emacs af, zal de titel terug veranderen in “zsh”. Dit is erg handig voor het bijhouden van vensters, en het kan ook bijzonder nuttig zijn in specifieke situaties, zoals wanneer je een lang lopend proces in een ander venster hebt dat je af en toe om invoer vraagt met emacs; de vensternaam zou veranderen in “dialog” wanneer dat gebeurt, zodat je zou weten dat je naar dat venster moest overschakelen en iets moest doen. dialog zelf. Je kunt gemakkelijk wisselen, hernoemen, enz. en je kunt vensters verplaatsen en delen tussen sessies. Het heeft ook een ander model, waarbij elke gebruiker een server heeft die zijn/haar sessies controleert en waarmee de client verbinding maakt. Het nadeel hiervan is dat als de server crasht, je alles kwijt bent; ik heb echter nog nooit gehad dat de server bij mij crashte. tmux lijkt actiever ontwikkeld te worden. Er zijn vrij regelmatig updates, en je kunt een bug report of feature request indienen volgens deze FAQ en binnen een paar dagen een antwoord krijgen. Dat zijn alleen de belangrijkste dingen die me meteen te binnen schieten. Er zijn ook andere kleine dingen, en ik weet zeker dat ik nog dingen vergeet. Maar het is zeker de moeite waard om tmux eens te proberen.
(Sessies zijn verzamelingen van vensters die kunnen worden losgemaakt en later weer kunnen worden aangekoppeld. Vensters kunnen een of meer panelen bevatten. Voor voorbeeldconfiguraties, zie hier en hier ).
TERM=tmux join-pane commando TERM=screen Een voordeel van screen: het is zo goed als out-of-the-box beschikbaar op Linux en Solaris. Wanneer je heen en weer moet schakelen tussen platforms, is het prettig om niet mentaal van context te hoeven wisselen.
Ik weet zeker dat je tmux op elk platform gecompileerd kunt krijgen, maar soms heb je net genoeg toegang om van screen gebruik te maken, maar de eigenlijke systeembeheerders willen niet echt software toevoegen die niet absoluut noodzakelijk is.
Ik gebruik tmux nu ongeveer 2 dagen, dus mijn ongebreidelde enthousiasme ervoor is nog niet getemperd door het raken van vervelende gebruikssituaties.
Terwijl ik door de gebruikelijke groeipijnen van de overgang van het ene programma naar het andere ging, viel mij een aantal positieve eigenschappen op, maar de eigenschap die mij doet geloven dat ik nooit meer terug naar het scherm ga, is het nut van de kopieer-n-plak modus.
In screen, kun je niet in de kopieermodus, scroll terug in de buffer, en ga dan naar een ander venster.
In tmux, kun je meerdere vensters tegelijk in kopieermodus hebben met de buffer teruggescrolld naar verschillende posities. Ook zijn er meerdere kopieer buffers. En je hoeft de bron niet te patchen om fFtT cursor beweging te krijgen.
De dingen die ik uit tmux haal die ik niet gemakkelijk in screen krijg zijn:
Ik heb GNU Screen in alle gevallen vervangen door tmux behalve in één geval - wanneer ik een HyperTerminal equivalent nodig heb om verbinding te maken met seriële poorten. Zoals Aaron Toponce opmerkte in zijn artikel “Connecting To Serial Null Modems With GNU Screen” , zegt de tmux FAQ :
screen heeft ingebouwde seriële en telnet ondersteuning; dit is bloat en zal waarschijnlijk niet aan tmux worden toegevoegd.
Mijn typische tmux use-case is om multi-pane en multi-window ontwikkelsessies te maken in combinatie met tmuxinator . Als u tmux wilt leren, raad ik u aan het boek van Brian P. Hogan, tmux: Productive Mouse-Free Development te kopen.
Ik ben al heel lang een intensief gebruiker van Screen, maar ik gebruik een versie die ik in 2002 heb aangepast. Voornamelijk omdat ik in staat wilde zijn om de window “next/prev” navigatievolgorde te laten overeenkomen met de volgorde waarin nieuwe windows werden gemaakt, vergelijkbaar met een tiling window manager zoals i3 of Ion . Het standaard gedrag van Screen is dat “next” en “prev” op vensternummer gaan, zodat gewoonlijk een “nieuw” venster (dat het kleinste beschikbare nummer pakt) zich elders bevindt dan het “volgende” venster - verwarrend als je de nummers niet onthoudt. Mijn voorkeursgedrag is sindsdien geïmplementeerd in Tmux als een vlag bij het new-window commando in 2010 , en de renumber-windows optie in 2012 . Mijn Screen patch, die ik zo acceptabel mogelijk probeerde te maken, inclusief toevoegingen aan de documentatie enzovoort, heeft geen enkele discussie opgeleverd op de Screen lijst in juli 2002 (toen “screen@informatik.uni-erlangen.de”, kan geen archieven vinden). In feite werd het niet eens erkend, zelfs niet toen ik het een jaar later opnieuw stuurde.
Sinds 2002 heb ik mijn patch een paar keer “gerebased” om toe te passen op nieuwere versies van Screen. Toen ik echter bij versie 4.3 (2015) kwam, merkte ik een ongedocumenteerde verandering op die een van mijn toepassingen van Screen kapot maakte - namelijk dat ‘stuff’ nu omgevingsvariabelen interpoleert . Ik had die functie niet nodig, en ik kon er niet achter komen hoe ik gemakkelijk het argument voor ‘stuff’ kon escapen (zodat ik tekst met dollartekens kon versturen), dus ik bleef versie 4.0 (uit 2004) gebruiken.
Ik gebruik Screen’s ‘stuff’ (‘send-keys’ in Tmux) in een Emacs functie die de inhoud van de huidige Emacs regio naar een specifiek vensternummer stuurt. Op die manier, als ik code schrijf in een scripttaal, open ik een interpreter, geef ik het intepreter venster een speciaal nummer, en dan kan ik regels code van mijn editor venster direct naar het interpreter venster sturen met behulp van deze Emacs binding. Het is een beetje hacky, maar ik vind het beter dan de pure-Emacs oplossing , omdat ik ook kan interageren met de interpreter in zijn Screen venster met standaard toetsaanslagen. Het lijkt een beetje op een GUI IDE, maar ik hoef de muis niet te gebruiken of naar een knipperende cursor te staren.
Een andere functie die ik in mijn patch heb geïmplementeerd is de mogelijkheid om een venster te “markeren”, en dan het gemarkeerde venster te verplaatsen naar de “volgende” na het huidige venster. Voor mij is dit een veel natuurlijker manier om vensters te herschikken dan hernummeren; het is als het copy/paste paradigma, of “drag-and-drop”. (Ik heb onlangs ontdekt hoe ik dit ook in i3 kan doen.)
Het zou mogelijk moeten zijn om hetzelfde te doen in Tmux, bijvoorbeeld vanaf 2015 is er een mogelijkheid om een venster te “markeren”. Of misschien kan een meer elementaire oplossing worden uitgewerkt met stateful shell scripts. Ik implementeerde een kort script en keybindings om de “marked pane” methode te proberen, en het werkte een paar keer, maar dan crashte Tmux met “[server kwijt]”. Toen ontdekte ik dat Tmux zelfs crashte zonder dat ik iets ingewikkelds probeerde te doen. Blijkbaar crasht het voor sommige gebruikers al een paar jaar op zijn minst . Soms crasht de server, soms gebruikt hij 100% van de CPU en reageert dan niet meer. Ik heb Screen nog nooit een van beide zien doen.
In theorie is Tmux in meerdere opzichten superieur aan Screen. Het heeft veel betere scriptbaarheid, wat betekent dat je dingen kunt doen zoals de lijst met vensters in de huidige sessie opvragen vanaf de opdrachtregel, wat onmogelijk is met Screen. Bijvoorbeeld in 2015 voegde Screen een commando toe om “vensters te sorteren op titel” . Ik weet niet zeker wanneer zo'n gespecialiseerd commando nuttig zou zijn, maar dit en meer praktische variaties (bijv. sorteer vensters op CPU-gebruik) zouden relatief eenvoudig kunnen worden gedaan vanuit een shellscript in Tmux. Het lijkt me moeilijk om zoiets creatiefs in Screen te doen, althans zonder de C-code aan te passen.
Zoals andere posters al zeiden, heeft Tmux een single-server model, wat ik zie als het voornaamste nadeel, vooral wanneer de server crasht. Het is mogelijk om dit te omzeilen door een aparte socket te specificeren voor iedere “sessie”. Toch geef ik de voorkeur aan Screen’s één-server-per-sessie standaard, die iets eleganter lijkt.
Werken met de Screen code, in 2002, was leerzaam en plezierig voor mij. Vreemd genoeg, voor al zijn extra mogelijkheden, heeft Tmux ongeveer 25% minder regels code dan Screen (30k vs 40k). Het viel me op dat Tmux veel boom- en lijst-gegevensstructuren gebruikt, die voor mij wat moeilijk te begrijpen waren. Screen leek de voorkeur te geven aan arrays.
Zoals ik het begrijp, omdat de Unix terminal interface zo stabiel is, is er weinig noodzaak voor de Screen of Tmux code om zich aan te passen aan veranderingen in het onderliggende besturingssysteem. Deze programma’s hebben niet echt beveiligingsupdates zoals webbrowsers of web servers of zelfs de shell. Ik heb geen problemen gemerkt bij het draaien van mijn aangepaste versie van Screen, voor het laatst bijgewerkt in 2004 (behalve dat ik enkele configuratiebestanden moest toevoegen om te voorkomen dat Systemd de socket ](https://www.freedesktop.org/software/systemd/man/tmpfiles.d.html) zou verwijderen; deze bestanden zijn toch al onderdeel van het distributiepakket). Misschien kan ik de problemen die ik in Tmux tegenkwam omzeilen door een Tmux-versie te draaien van voordat het begon te crashen. Natuurlijk, als genoeg gebruikers dit doen, is het niet erg goed voor nieuwe gebruikers, omdat het betekent dat minder experts op zoek zullen gaan naar bugs in de laatste officiële versies van deze programma’s. Het is echter moeilijk om mezelf te motiveren om over te stappen op een product dat voor mij onstabiel is (de nieuwste Tmux) of dat bepaalde functies mist die ik wil (standaard Screen).
Ik weet dat dit geen gemakkelijk antwoord is op de vraag van de OP, maar ik hoop dat mijn perspectief nuttig was.
Ik zou zeggen dat de beschikbaarheid van Screen zijn kracht is, maar zijn windowing systeem is niet zo gemakkelijk te hanteren als dat van tmux . Ik moet zeggen dat ik momenteel meestal gnu-screen gebruik en als resultaat heb ik veel terminal tabs in plaats van Screen vensters.
@Jed Schneider: Je kunt verticale pane splits krijgen metCtrl+A en dan | (verticale balk).