Je suis sur le point de revenir à l’utilisation de GNU Screen , mais j’ai entendu de temps à autre des gens dire que tmux était une meilleure alternative. Offre-t-il vraiment une alternative à toutes les fonctionnalités Écran offres, telles que la surveillance de l'activité dans différentes fenêtres, etc.? Quels sont les avantages et les inconvénients de chacun?
Certaines des (principales) raisons pour lesquelles je préfère tmux
à screen
:
tmux
peuvent être exécutées à partir d'un shell avec tmux command [args]
. Cela le rend très facilement scriptable, et facilite également l'exécution de commandes complexes.screen
définit le titre en fonction du premier mot de la commande et demande à la configuration de Shell de le faire même dans une fenêtre Shell, tmux
enregistre les processus en cours d'exécution dans chaque fenêtre et met à jour le titre en conséquence. De cette façon, vous obtenez un renommage dynamique avec n'importe quel shell et aucune configuration. Par exemple: Disons que vous utilisez Z Shell; le nom de la fenêtre serait "zsh". Supposons maintenant que vous souhaitiez modifier un fichier de configuration. Vous devez donc saisir Sudo emacs /etc/somefile
. Tandis que Sudo vous demande votre mot de passe, le nom de la fenêtre sera "Sudo", mais une fois que vous avez fait cela et que Sudo
lance emacs
, le titre sera "emacs". Lorsque vous avez terminé et que vous quittez emacs
, le titre redevient "zsh". Ceci est très utile pour garder une trace des fenêtres et peut être particulièrement utile dans des situations spécifiques, comme si vous avez un processus de longue durée dans une autre fenêtre qui vous invite occasionnellement à entrer en utilisant dialog
; le nom de la fenêtre se changerait en "dialogue" lorsque cela se produirait, afin que vous sachiez que vous deviez passer à cette fenêtre et faire quelque chose.tmux
lui-même. Vous pouvez facilement changer, renommer, etc. et vous pouvez déplacer et partager des fenêtres entre les sessions. Il a également un modèle différent, où chaque utilisateur possède un serveur qui contrôle ses sessions et auquel le client se connecte. L'inconvénient est que si le serveur tombe en panne, vous perdez tout. Je n'ai jamais eu le crash du serveur sur moi, cependant.tmux
semble être développé plus activement. Il y a des mises à jour assez fréquentes, et vous pouvez déposer un rapport de bogue ou une demande de fonctionnalité conformément à cette FAQ et obtenir une réponse dans quelques jours.Ce ne sont que les principales choses qui viennent immédiatement à l’esprit. Il y a aussi d'autres petites choses et je suis sûr d'oublier certaines choses. Cela vaut vraiment la peine d'essayer tmux
, cependant.
() Les sessions sont des collections de fenêtres pouvant être détachées et rattachées ultérieurement. Windows peut contenir un ou plusieurs volets . Par exemple, consultez la section ici et ici . )
TERM=tmux
join-pane
TERM=screen
Un pro pour screen: il est disponible directement sous Linux et Solaris. Lorsque vous devez basculer d'une plate-forme à l'autre, il est agréable de ne pas changer de contexte mental.
Je suis sûr que tmux peut être compilé sur n’importe quelle plate-forme, mais vous avez parfois juste assez d’accès pour utiliser screen, mais les administrateurs système ne souhaitent pas vraiment ajouter de logiciel qui n’est pas absolument nécessaire.
J'utilise tmux depuis environ 2 jours maintenant, donc mon enthousiasme débridé pour celui-ci n'a pas encore été tempéré par des cas d'utilisation ennuyeux. Alors que je passais par les difficultés de croissance habituelles liées à la transition d’un programme à l’autre, j’ai été frappé par plusieurs caractéristiques positives, mais la caractéristique qui me fait croire que je ne reviendrai jamais à l’écran est l’utilité du mode copier-coller. À l'écran, vous ne pouvez pas entrer en mode copie, revenir en arrière dans la mémoire tampon, puis passer à une autre fenêtre. Dans tmux, vous pouvez avoir plusieurs fenêtres simultanément en mode copie avec la mémoire tampon défilée à différentes positions. En outre, il existe plusieurs tampons de copie. Et vous n'avez pas besoin de patcher la source pour obtenir le mouvement du curseur fFtT.
Les choses que je tire de tmux ne me parviennent pas facilement à l'écran:
J'ai remplacé GNU Screen avec tmux dans tous les cas d'utilisation sauf un - lorsque j'ai besoin d'un HyperTerminal équivalent pour se connecter à des ports série. Comme Aaron Toponce l’a noté dans son article "Connexion à des modems série nuls avec GNU Screen" , le tmux FAQ indique:
screen possède un support série et telnet intégré; c'est énorme et il est peu probable qu'il soit ajouté à tmux.
Mon exemple typique de tmux use est de créer des sessions de développement à volets multiples et à fenêtres multiples en combinaison avec tmuxinator . Si vous voulez apprendre tmux , je vous recommande de vous procurer le livre de Brian P. Hogan, tmux: développement productif sans souris .
Je dirais que la disponibilité de l’écran est sa force, mais son système de fenêtrage n’est pas aussi facile à gérer que tmux Je dois dire que j'utilise gnu-screen la plupart du temps à l'heure actuelle et que, par conséquent, j'ai beaucoup d'onglets de terminal au lieu de fenêtres Screen.
@Jed Schneider: Vous pouvez obtenir des divisions de volet vertical avec Ctrl+A et alors | (barre verticale).
Un des responsables de tmux, Thomas Adam, est également répertorié en tant que responsable du projet screen
bien qu'il ne touche que le code de tmux. C'est un énorme avantage de tmux sur écran.
Cela fait longtemps que je suis un grand utilisateur de Screen, mais j’utilise une version que j’ai modifiée en 2002. Principalement parce que je voulais pouvoir faire en sorte que la fenêtre "suivant/précédent" trie les commandes de navigation dans l’ordre dans lequel les nouvelles Des fenêtres ont été créées, similaires à un gestionnaire de fenêtres en mosaïque tel que i3 ou Ion . Le comportement standard de l'écran est que 'next' et 'prev' passent par le numéro de la fenêtre. Ainsi, une 'nouvelle' fenêtre (capturant le plus petit numéro disponible) sera située ailleurs que dans la 'fenêtre suivante' - ce qui déroutera si vous ne le faites pas. souviens pas des chiffres. Mon comportement préféré a depuis été implémenté dans Tmux en tant que un indicateur de la commande new-window en 2010 , et l'option renumber-windows en 2012 . Le correctif My Screen, que j’essayais de rendre aussi acceptable que possible, y compris les ajouts de documentation, etc., n’a généré aucune discussion sur la liste Screen en juillet 2002 (alors "[email protected]", trouver des archives). En fait, cela n'a même pas été reconnu, même lorsque je l'ai renvoyé un an plus tard.
Depuis 2002, j'ai "rebasé" mon correctif à quelques reprises pour l'appliquer aux nouvelles versions de Screen. Cependant, quand je suis arrivé à la version 4.3 (2015), j'ai remarqué un changement non documenté qui a cassé une de mes utilisations d'écran - à savoir que 'substance' interpole maintenant les variables d'environnement . Je n'avais pas besoin de cette fonctionnalité et je n'arrivais pas à comprendre comment échapper facilement à l'argument de '' trucs '' (pour pouvoir envoyer du texte contenant des signes dollar). Je n'ai donc cessé d'utiliser la version 4.0 (à partir de 2004).
J'utilise le "matériel" de Screen ("send-keys" dans Tmux) dans une fonction Emacs qui envoie le contenu de la région Emacs actuelle à un numéro de fenêtre spécifique. Ainsi, lorsque j'écris du code dans un langage de script, j'ouvre un interpréteur, je donne un numéro spécial à la fenêtre interpréteur, puis je peux envoyer des lignes de code de ma fenêtre d'édition directement à la fenêtre interpréteur à l'aide de cette liaison Emacs. C'est hacky mais je l'aime mieux que la solution pure-Emacs , car je peux aussi interagir avec l'interprète dans sa fenêtre Screen en utilisant des frappes au clavier standard. C'est un peu comme un IDE GUI, mais je n'ai pas besoin d'utiliser la souris ou de regarder fixement un curseur clignotant.
Une autre fonctionnalité implémentée dans mon patch est la possibilité de "marquer" une fenêtre, puis de repositionner la fenêtre marquée pour qu'elle soit "suivante" après la fenêtre actuelle. Pour moi, il s'agit d'une manière beaucoup plus naturelle de réorganiser les fenêtres que de renuméroter; c'est comme le paradigme copier/coller, ou "glisser-déposer". (Je j'ai récemment compris comment faire cela dans i3 aussi.)
Il devrait être possible de faire la même chose dans Tmux, par exemple à partir de 2015 il existe une possibilité de "marquer" un volet. Ou peut-être qu'une solution plus élémentaire pourrait être élaborée avec des scripts Shell dynamiques. J'ai implémenté un court script et des raccourcis clavier pour essayer la méthode "volet marqué", et cela a fonctionné à quelques reprises, mais Tmux s'est écrasé alors avec "[serveur perdu]". Ensuite, j'ai trouvé Tmux en panne, même sans que j'essaye de faire quelque chose de compliqué. Apparemment il s'est écrasé pour certains utilisateurs depuis quelques années au moins . Parfois, le serveur tombe en panne, parfois, il commence à utiliser 100% de la CPU et ne répond plus. Je n'ai jamais vu Screen faire l'un ou l'autre.
En théorie, Tmux est supérieur à Screen à plusieurs égards. La scriptabilité est bien meilleure, ce qui signifie que vous pouvez, par exemple, interroger la liste des fenêtres de la session en cours à partir de la ligne de commande, ce qui est impossible avec Screen. Par exemple, en 2015, Screen a ajouté une commande permettant de "trier les fenêtres par titre" . Je ne sais pas quand une commande aussi spécialisée serait utile, mais cette variante et d'autres variantes pratiques (par exemple, le tri des fenêtres en fonction de l'utilisation du processeur) pourraient être effectuées relativement facilement à partir d'un script Shell dans Tmux. Il me semble difficile de faire quelque chose d'aussi créatif dans Screen, du moins sans modifier le code C.
Comme d'autres affiches l'ont mentionné, Tmux a un modèle à serveur unique que je considère comme le principal inconvénient, en particulier lorsque le serveur tombe en panne. Il est possible de contourner ce problème en spécifiant un socket distinct pour chaque "session". Je préfère tout de même le paramètre par défaut d’un serveur par session de Screen, qui semble légèrement plus élégant.
Travailler avec le code Screen, en 2002, était pour moi une expérience éducative et agréable. Curieusement, pour toutes ses fonctionnalités supplémentaires, Tmux a environ 25% de lignes de code en moins que Screen (30k vs 40k). J'ai remarqué que Tmux utilise de nombreuses structures de données arborescentes et listées, difficiles à comprendre pour moi. L'écran semblait préférer les tableaux.
Si j'ai bien compris, l'interface de terminal Unix étant très stable, il est inutile que le code Screen ou Tmux s'adapte aux modifications du système d'exploitation sous-jacent. Ces programmes ne disposent pas vraiment de mises à jour de sécurité telles que les navigateurs Web, les serveurs Web ou même le shell. Je n'ai pas remarqué de problèmes pour exécuter ma version personnalisée de Screen, mise à jour pour la dernière fois en 2004 (excepté la nécessité d'ajouter certains fichiers de configuration pour empêcher Systemd de supprimer le socket ; ces fichiers font en tout cas partie du paquet de distribution) . Je pourrais peut-être simplement contourner les problèmes que j'ai rencontrés dans Tmux en exécutant une version de Tmux antérieure à son crash. Bien sûr, si suffisamment d'utilisateurs le font, cela ne sera pas très utile pour les nouveaux utilisateurs, car cela signifie que moins d'experts rechercheront des bogues dans les dernières versions officielles de ces programmes. Cependant, il est difficile de me motiver pour passer à un produit qui est instable pour moi (dernier Tmux) ou qui manque de certaines fonctionnalités que je souhaite (écran standard).
Je sais que cela ne fournit pas une réponse facile à la question du PO, mais j'espère que mon point de vue a été utile.