( Sessions sont des collections de Windows qui peuvent être détachés et rattachés plus tard. Les fenêtres peuvent contenir un ou plusieurs vitres . Pour des exemples de configuration, consultez aquí y aquí .)

tmux

• Pour
  • Peut envoyer des touches à d'autres volets, un peu comme un IDE
  • Combinaisons de touches faciles - avec la bonne configuration, vous vous sentirez comme chez vous depuis Vim ou Screen.
  • Liaisons Vim-ish et Emacs-ish intégrées
  • Bonne gestion de la mise en page, un peu comme un gestionnaire de fenêtres en mosaïque.
  • Unicode semble fonctionner avec les terminaux modernes.
  • Quelques problèmes de terminal corrigés avec TERM=tmux
• Cons
  • Lenteur - je ne sais pas pourquoi, mais les frappes au clavier semblent lentes. Plus de problèmes de lenteur
  • Le multiplexage impose la largeur et la hauteur de toute la session au plus petit terminal connecté.
  • A planté plusieurs fois sous Mac OS X, perdant toute la session.
  • A échoué sur Linux après la mise à jour, où je n'ai pas pu me reconnecter à mon ancienne session.
  • Manque parfois la saisie des commandes - ^A ^[ prend quelques essais pour le mode copie
  • Impossible de déplacer un volet d'une fenêtre à l'autre Fixé avec le join-pane commande
  • Pas de déballage des lignes (ou "reflow" ou "rewrap") après un changement de largeur du terminal (redimensionnement de la fenêtre)

Écran GNU

• Pour
  • Extrêmement stable (la v1.0 date de 1987)
  • Quelques problèmes de terminal corrigés avec TERM=screen
  • Liaisons Emacs intégrées
  • Des vitres horizontales faciles à déplacer et à contrôler
  • En cas de multiplexage, tout terminal connecté peut redimensionner un volet.
• Cons
  • Pas de scissions verticales sans patch (sauf sur Ubuntu) Les versions plus récentes de l'écran prennent en charge les divisions verticales
  • La séparation des vitres est perdue lors du détachement
  • Faire fonctionner Unicode demande un peu de finesse et de détermination
  • Configuration complexe et confuse de la ligne d'état

Un avantage pour screen : il est disponible pratiquement prêt à l'emploi sur Linux et Solaris. Lorsque vous devez passer d'une plate-forme à l'autre, il est agréable de ne pas avoir à changer mentalement de contexte.

Je suis sûr que vous pouvez faire compiler tmux sur n'importe quelle plateforme, mais parfois vous avez juste assez d'accès pour utiliser l'écran, mais les administrateurs du système actuel ne veulent pas vraiment ajouter un logiciel qui n'est pas absolument nécessaire.

J'ai utilisé tmux depuis environ deux jours maintenant, de sorte que mon enthousiasme débridé à son égard n'a pas encore été tempéré par des cas d'utilisation gênants.

En passant par les douleurs habituelles de la transition d'un programme à un autre, j'ai été frappé par plusieurs fonctionnalités positives, mais la fonctionnalité qui me fait croire que je ne reviendrai jamais à l'écran est l'utilité du mode copier-coller.

Sur screen vous ne pouvez pas entrer en mode copie, revenir en arrière dans la mémoire tampon, puis passer à une autre fenêtre.

Sur tmux Avec la fonction de copie, vous pouvez avoir plusieurs fenêtres en même temps en mode copie avec le tampon qui défile vers différentes positions. De plus, il existe plusieurs tampons de copie. Et vous n'avez pas besoin de patcher la source pour obtenir le mouvement du curseur fFtT.

J'ai remplacé Écran GNU con tmux dans tous les cas sauf un : quand j'ai besoin d'une HyperTerminal équivalent pour se connecter aux ports série. Comme l'a noté Aaron Toponce dans son article "Connexion à des modems nuls en série avec GNU Screen" le FAQ tmux États :

l'écran a un support intégré pour la série et le telnet ; c'est un bloat et il est improbable d'être ajouté à tmux.

Mes habitudes tmux Le cas d'utilisation est la création de sessions de développement multi-volets 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 : Développement productif sans souris .

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 des fenêtres "suivant/précédent" corresponde à l'ordre dans lequel les nouvelles fenêtres sont créées, comme dans un gestionnaire de fenêtres à tuiles tel que i3 o Ion . Le comportement standard de Screen est que 'next' et 'prev' vont par numéro de fenêtre, de sorte que généralement une 'nouvelle' fenêtre (en prenant le plus petit numéro disponible) sera située ailleurs que la 'prochaine' fenêtre - déroutant si vous ne vous souvenez pas des numéros. Mon comportement préféré a depuis été implémenté dans Tmux comme suit un drapeau pour la commande new-window en 2010 et le option de renumérotation de Windows en 2012 . Mon correctif Screen, que j'ai essayé de rendre aussi acceptable que possible, y compris en ajoutant de la documentation et ainsi de suite, n'a suscité aucune discussion sur la liste Screen en juillet 2002 (alors "screen@informatik.uni-erlangen.de", je ne trouve pas les 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 aux nouvelles versions de Screen. Cependant, lorsque je suis arrivé à la version 4.3 (2015), j'ai remarqué un changement non documenté qui a cassé 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 n'arrivais pas à trouver comment échapper facilement à l'argument "stuff" (pour pouvoir envoyer du texte contenant des signes de dollar). J'ai donc continué à utiliser la version 4.0 (de 2004).

J'utilise le 'stuff' 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. De cette façon, lorsque j'écris du code dans un langage de script, j'ouvre un interpréteur, je donne à la fenêtre de l'interpréteur un numéro spécial, et ensuite je peux envoyer des lignes de code de ma fenêtre d'éditeur directement à la fenêtre de l'interpréteur en utilisant cette liaison Emacs. C'est un peu compliqué mais je préfère cela à la solution Emacs pure En effet, je peux également interagir avec l'interprète dans sa fenêtre d'écran en utilisant les 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". (I J'ai récemment découvert comment faire cela dans i3. également).

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 Shell Shell à état. J'ai implémenté un court Shell et des liaisons de touches pour essayer la méthode du "volet marqué", et cela a fonctionné quelques fois mais ensuite Tmux a planté avec "[lost server]". Ensuite, j'ai constaté que Tmux plantait même sans que j'essaie de faire quoi que ce soit de compliqué. Apparemment, certains utilisateurs se sont plantés para quelques années au moins . Parfois le serveur se plante, parfois il commence à utiliser 100% du CPU et ne répond plus. Je n'ai jamais vu Screen faire l'un ou l'autre de ces cas.

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 de Windows dans la session actuelle à partir de la ligne de commande, ce qui est impossible avec Screen. Par exemple, en 2015, Screen Ajout d'une commande pour "trier les fenêtres par titre". . Je ne suis pas sûr qu'une telle commande spécialisée soit utile, mais ceci et des variations plus pratiques (par exemple, trier Windows par utilisation du CPU) pourraient relativement facilement être faits à partir d'un Shell Shell dans Tmux. Il me semblerait difficile de faire quelque chose d'aussi créatif dans Screen, du moins sans modifier le code C.

Comme d'autres posters l'ont mentionné, Tmux a un modèle à serveur unique, ce 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 séparé pour chaque "session". Je préfère néanmoins le modèle par défaut de Screen, un serveur par session, qui semble légèrement plus élégant.

Travailler avec le code Screen, en 2002, a été é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 beaucoup de structures de données de type arbre et liste, qui étaient légèrement difficiles à comprendre pour moi. Screen semblait préférer les tableaux.

D'après ce que j'ai compris, l'interface du terminal Unix étant très stable, il n'est pas nécessaire que le code de Screen ou de Tmux s'adapte aux changements du système d'exploitation sous-jacent. Ces programmes n'ont pas vraiment de mises à jour de sécurité comme les navigateurs web 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 (à l'exception de la nécessité de rajouter certains fichiers de configuration pour éviter que Systemd ne supprime 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 exécutant une version de Tmux antérieure à celle qui a commencé à planter. Bien sûr, si suffisamment d'utilisateurs font cela, ce ne sera pas très bon pour les nouveaux utilisateurs, puisque cela signifie que moins d'experts chercheront les 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 (la dernière version de Tmux) ou qui manque de certaines fonctionnalités que je veux (Screen 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.