Je suis sur le point de me remettre à utiliser GNU Screen , mais j'ai entendu des gens mentionner occasionnellement tmux comme une meilleure alternative. Offre-t-il vraiment une alternative à toutes les fonctionnalités offertes par Screen , telles que la surveillance de l'activité dans différentes fenêtres, etc. Quels sont les avantages et les inconvénients de chacune d'entre elles ?
Quelques-unes des raisons (majeures) pour lesquelles je préfère le tmux au screen :
tmux peuvent être exécutées à partir d'un shell avec tmux command [args]. Cela rend le script très facile à utiliser, ainsi que l'exécution de commandes complexes. screen définit le titre en fonction du premier mot de la commande, et nécessite une configuration du shell pour le faire même dans une fenêtre shell, tmux garde une trace des processus réellement exécutés dans chaque fenêtre, et met à jour le titre en conséquence. De cette façon, vous obtenez un renommage dynamique avec n'importe quelle configuration shell et zéro. Par exemple : Supposons que vous exécutez le shell Z ; le nom de la fenêtre serait “zsh”. Maintenant, disons que vous voulez modifier un fichier de configuration, donc vous tapez sudo emacs /etc/somefile. Pendant que sudo vous demande votre mot de passe, le nom de la fenêtre sera “sudo”, mais une fois que vous aurez fait cela et que sudo lancera emacs, le titre sera “emacs”. Lorsque vous aurez terminé et que vous aurez quitté emacs, le titre redeviendra “zsh”. C'est assez utile pour garder une trace des fenêtres, et cela peut aussi être particulièrement utile dans des situations spécifiques, comme si vous avez un processus de longue haleine dans une autre fenêtre qui vous demande occasionnellement d'entrer des données en utilisant dialog ; le nom de la fenêtre changera en “dialogue” quand cela se produira, de sorte que vous saurez que vous devez passer à cette fenêtre et faire quelque chose. tmux même. Vous pouvez facilement changer, renommer, etc. et vous pouvez déplacer et partager des fenêtres entre les sessions. Il existe également un modèle différent, où chaque utilisateur dispose d'un serveur qui contrôle ses sessions et auquel le client se connecte. L'inconvénient est que si le serveur plante, vous perdez tout ; je n'ai jamais eu de panne de serveur sur moi, cependant. Le modèle tmux semble être plus activement développé. Les mises à jour sont assez fréquentes, et vous pouvez déposer un rapport de bogue ou une demande de fonctionnalité selon cette FAQ et obtenir une réponse dans les jours qui suivent. Ce ne sont là que les principales choses qui me viennent immédiatement à l'esprit. Il y a aussi d'autres petites choses, et je suis sûr que j'en oublie certaines. Mais ça vaut vraiment la peine d'essayer tmux.
(Les Sessions sont des collections de fenêtres qui peuvent être détachées et rattachées ultérieurement. Les fenêtres peuvent contenir un ou plusieurs panneaux. Par exemple, les configurations, consultez ici et ici )
TERM=tmux join-pane TERM=screen Un pro pour l'écran : il est disponible à peu près prêt à l'emploi sur Linux et Solaris. Lorsque vous devez passer d'une plate-forme à l'autre, il est bon de ne pas avoir à changer de contexte mental.
Je suis sûr que vous pouvez obtenir tmux compilé sur n'importe quelle plate-forme, mais parfois vous avez juste assez d'accès pour utiliser l'écran, mais les administrateurs système actuels ne veulent pas vraiment ajouter de logiciels qui ne sont pas absolument nécessaires.
J'utilise tmux depuis environ 2 jours maintenant, donc mon enthousiasme débridé pour ce produit n'a pas encore été tempéré par des cas d'utilisation ennuyeux.
Tout en traversant les difficultés habituelles de la transition d'un programme à l'autre, j'ai été frappé par plusieurs caractéristiques positives, mais celle qui me fait croire que je ne retournerai jamais à l'écran est l'utilité du mode copier-coller.
Dans screen, vous ne pouvez pas entrer en mode copie, revenir en arrière dans la mémoire tampon, puis aller dans une autre fenêtre.
Dans tmux, vous pouvez avoir plusieurs fenêtres simultanément en mode de copie avec le tampon défilant vers l'arrière à différentes positions. Il existe également 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 retire des tmux que je n'obtiens pas facilement à l'écran sont :
J'ai remplacé GNU Screen par tmux dans tous les cas d'utilisation sauf un, lorsque j'ai besoin d'un HyperTerminal équivalent pour me connecter à des ports série. Comme Aaron Toponce l'a noté dans son article “Connexion aux modems nuls en série avec GNU Screen” , la tmux FAQ l'indique :
écran a un support série et telnet intégré ; c'est du gonflement et il est peu probable qu'il soit ajouté à tmux.
Mon cas d'utilisation typique de tmux est de créer des sessions de développement multi-vitres et multi-fenêtres en combinaison avec tmuxinator . Si vous voulez apprendre tmux , je vous recommande de vous procurer le livre de Brian P. Hogan, tmux : Productive Mouse-Free Development .
Je suis un grand utilisateur de Screen depuis longtemps, mais j'utilise une version que j'ai modifiée en 2002. Principalement parce que je voulais que l'ordre de navigation “suivant/précédent” des fenêtres corresponde à l'ordre dans lequel les nouvelles fenêtres étaient créées, un peu comme un gestionnaire de fenêtres à carreaux comme i3 ou Ion . Le comportement standard de l'écran est que les fenêtres “suivante” et “précédente” sont classées par numéro de fenêtre, de sorte qu'en général, une “nouvelle” fenêtre (saisissant le plus petit numéro disponible) se trouve ailleurs que dans la fenêtre “suivante”, ce qui est déroutant si vous ne vous souvenez pas des numéros. Mon comportement préféré a depuis été implémenté dans Tmux comme un drapeau pour la commande de nouvelle fenêtre en 2010 , et l'option renuméroter les fenêtres en 2012 . Mon patch Screen, que j'ai essayé de rendre aussi acceptable que possible, y compris les ajouts de documentation et ainsi de suite, n'a généré aucune discussion sur la liste Screen en juillet 2002 (alors “screen@informatik.uni-erlangen.de”, ne trouve pas d'archives). En fait, il n'a même pas été reconnu, même lorsque je l'ai envoyé à nouveau un an plus tard.
Depuis 2002, j'ai “rebasé” mon patch plusieurs fois pour l'appliquer à des versions plus récentes de Screen. Cependant, lorsque je suis arrivé à la version 4.3 (2015), j'ai remarqué un changement non documenté qui a brisé l'une de mes utilisations de Screen - à savoir que “stuff” interpole maintenant les variables d'environnement . Je n'avais pas besoin de cette fonctionnalité et je ne savais pas comment échapper facilement à l'argument du “stuff” (pour pouvoir envoyer du texte contenant des signes de dollar), alors j'ai continué à utiliser la version 4.0 (de 2004).
J'utilise les “trucs” 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ète, je donne à la fenêtre de l'interprète un numéro spécial, et je peux alors envoyer des lignes de code de ma fenêtre d'éditeur directement à la fenêtre de l'interprète en utilisant cette liaison Emacs. C'est hacky, mais je le préfère à la solution Emacs pure , car je peux aussi interagir avec l'interprète dans sa fenêtre Screen en utilisant des touches standard. C'est un peu comme un IDE GUI, mais je n'ai pas besoin d'utiliser la souris ou de fixer un curseur clignotant.
Une autre fonctionnalité que j'ai 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, c'est une façon beaucoup plus naturelle de réorganiser les fenêtres que de les renuméroter ; c'est comme le paradigme copier/coller, ou “glisser-déposer”. Il devrait être possible de faire la même chose dans Tmux, par exemple à partir de 2015 il existe une possibilité de “marquer” une vitre. Ou peut-être qu'une solution plus élémentaire pourrait être élaborée avec des scripts shell avec état. J'ai implémenté un court script et des raccourcis clavier pour essayer la méthode du “panneau marqué”, et cela a fonctionné quelques fois mais ensuite Tmux a planté avec “[serveur perdu]”. Puis j'ai constaté que Tmux plantait même sans que j'essaie de faire quelque chose de compliqué. Apparemment il a planté pour certains utilisateurs depuis quelques années au moins . Parfois le serveur plante, parfois il commence à utiliser 100% du CPU et ne répond plus. Je n'ai jamais vu Screen faire ni l'un ni l'autre.
En théorie, Tmux est supérieur à Screen à plusieurs égards. Il a une bien meilleure scriptabilité, ce qui signifie que vous pouvez faire des choses comme interroger la liste des fenêtres de la session en cours depuis la ligne de commande, ce qui est impossible avec Screen. Par exemple, en 2015, Screen a ajouté une commande pour “trier les fenêtres par titre” . Je ne sais pas quand une telle commande spécialisée serait utile, mais cette commande et des variantes plus pratiques (par exemple, trier les fenêtres en fonction de l'utilisation du processeur) pourraient relativement facilement être réalisées à partir d'un script shell dans Tmux. Il me semble difficile de faire quelque chose d'aussi créatif dans Screen, au moins sans modifier le code C.
Comme d'autres affiches l'ont mentionné, Tmux a un modèle à un seul serveur, ce que je considère comme le principal inconvénient, en particulier lorsque le serveur plante. Il est possible de contourner ce problème en spécifiant une socket séparée pour chaque “session”. Je préfère néanmoins le modèle par défaut d'un serveur par session de Screen, qui me semble un peu plus élégant.
Travailler avec le code de Screen, en 2002, était éducatif et agréable pour moi. Curieusement, malgré toutes ses fonctionnalités supplémentaires, Tmux a environ 25% de lignes de code en moins que Screen (30k contre 40k). J'ai remarqué que Tmux utilise de nombreuses structures de données en arborescence et en liste, qui m'ont été légèrement difficiles à comprendre. Screen semblait préférer les tableaux.
D'après ce que je comprends, l'interface du terminal Unix étant très stable, le code de Screen ou de Tmux a peu besoin de s'adapter aux changements du système d'exploitation sous-jacent. Ces programmes n'ont pas vraiment de mises à jour de sécurité comme les navigateurs ou les serveurs web ou même le shell. Je n'ai pas remarqué de problèmes pour faire fonctionner ma version personnalisée de Screen, mise à jour pour la dernière fois en 2004 (sauf qu'il faut ajouter quelques fichiers de configuration pour empêcher Systemd de supprimer la socket ; ces fichiers font généralement partie du paquet de distribution de toute façon). Je pourrais peut-être contourner les problèmes que j'ai rencontrés dans Tmux en lançant une version de Tmux avant qu'elle ne plante. Bien sûr, si un nombre suffisant d'utilisateurs le font, ce ne sera pas très bon pour les nouveaux utilisateurs, car cela signifie que moins d'experts chercheront des bogues dans les dernières versions officielles de ces programmes. Cependant, il est difficile de me motiver à passer à un produit qui est instable pour moi (dernière version de 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 de l'OP, mais j'espère que mon point de vue a été utile.
Je dirais que la disponibilité de l'écran est son point fort, mais son système de fenêtrage n'est pas aussi facile à manipuler que celui de 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 séparations verticales de fenêtres avecCtrl+A et ensuite | (barre verticale).