- L’auteur a utilisé tmux pendant longtemps, mais a récemment commencé à douter de sa complexité et de ses limites (compatibilité des couleurs, scrollback, copie à la souris, absence de prise en charge de certains protocoles, etc.)
- Les fonctions clés de tmux, comme la persistance de session (
detach/attach) ou le fractionnement et la gestion des fenêtres, ne nécessitent pas forcément tmux - En s’appuyant sur des outils légers fidèles à la philosophie Unix, comme dtach, abduco, shpool, on peut se concentrer uniquement sur la gestion de session tout en conservant un scrollback natif et davantage de simplicité
- En particulier, la combinaison
shpool+ ssh permet de gérer directement plusieurs sessions distantes avec le gestionnaire de fenêtres, tout en continuant à utiliser les fonctions natives (notifications, défilement, titres, etc.) - Ce n’est pas parfait, mais selon l’auteur cela a permis de remplacer complètement tmux, avec à la clé un workflow plus simple et plus facile à maintenir
Avantages et limites de tmux
- La persistance de session (
detach/attach) et la gestion des fenêtres (onglets, splits) constituaient le cœur du workflow fourni jusque-là par tmux - Mais sans configuration correcte de
TERM, des problèmes de rendu des couleurs apparaissent, et il faut aussi tenir compte des interactions entre le terminal et tmux, ce qui augmente la complexité - L’utilisation du tampon de défilement impose aussi d’apprendre le fonctionnement propre à tmux, et la copie de zones à la souris était peu pratique dans un environnement avec splits
- La prise en charge de nouvelles fonctions de terminal comme le kitty graphics protocol est insuffisante, et certains protocoles expérimentaux ne sont pas pris en charge
- Certains critiquent aussi le fait que, en réinterprétant à nouveau les escape codes et en ajoutant ses propres concepts de session et de fenêtre, un multiplexeur freine l’évolution de l’écosystème des terminaux
Explorer des alternatives à tmux
- Persistance de session :
- Des solutions simples comme
ctrl-z+fg,nohup,disownexistent, mais elles remplacent difficilement complètement tmux - Plusieurs outils conçus pour uniquement préserver la session sont apparus (
dtach, abduco, shpool)- Ils s’appuient sur une combinaison de
fork()et de sockets UNIX pour relier daemon et client - Contrairement à tmux, sans split virtuel, ils permettent un scrollback natif et offrent parfois une restauration du tampon
- Ils s’appuient sur une combinaison de
- D’après l’expérience de l’auteur, la plupart de ces outils alternatifs manquent de maturité, avec des bugs ou des raccourcis de détachement qui ne fonctionnent pas dans
nvim - Seul shpool lui a semblé suffisamment abouti, notamment sur les commandes
detach/attachet la personnalisation des raccourcis clavier
- Des solutions simples comme
- Gestion des fenêtres :
- En local, le fractionnement et l’agencement sont gérés par le gestionnaire de fenêtres
- Même à distance (en SSH), la combinaison de ssh_config et shpool permet de conserver plusieurs sessions indépendantes dans des fenêtres séparées
- Associé à autossh, cela permet de conserver les sessions même lors des reconnexions réseau
Nouveau workflow
- L’auteur utilise personnellement ghostty (sur son portable) et sway+foot (sur son PC personnel) pour la gestion des fenêtres. Les serveurs tournent sur des VM headless basées sur Proxmox, avec un environnement de développement toujours accessible en SSH
- Plusieurs sessions shpool sont connectées automatiquement via des raccourcis ssh, puis contrôlées indépendamment par le gestionnaire de fenêtres local
- Dans
ssh_config, l’attachement à une session shpool est automatisé pour chaque hôte - Chaque terminal peut se connecter séparément à IRC, à la gestion des dotfiles, à un environnement neovim distinct, etc. pour des sessions multiples indépendantes
- Dans
- Le défilement natif, les notifications, les titres de terminal et d’autres fonctions que tmux gérait de manière instable fonctionnent au contraire plus naturellement
- Il y a aussi des inconvénients : délai de restauration de l’état du terminal lors de la reconnexion à vim, et problèmes de redimensionnement avec
nvim- Pas de prise en charge multi-utilisateur/multi-client (conflit de session si plusieurs clients lancent autossh en même temps)
- Mais, selon les critères de l’auteur, le remplacement complet de tmux est réussi
Conclusion
- Ce n’est pas exactement identique, mais il est possible de passer à un workflow de gestion de session plus simple et plus flexible, libéré de la complexité et des limites de tmux
- Selon votre workflow, des outils alternatifs comme shpool peuvent valoir le détour
7 commentaires
Aujourd’hui, on génère et utilise des choses comme tmux avec l’IA. Avec Xterm.js + react + electron, en 3 à 4 heures on peut en sortir 100 comme ça, puis si besoin les modifier en temps réel et s’en servir, un peu comme un shabu-shabu ? On met ce qu’on a envie de manger et on en met à fond dans le code source.
Je l’utilise confortablement avec wezterm.
Screen, c’est le top !
cargo install shpool... non, je vais juste utiliser tmux... il faut des paquets différents selon l'OS !Il y a un excellent nouveau venu appelé Zellij. Je le recommande vivement.
Zellij - terminal pour développeurs & Ops
Je l’avais aussi posté il y a assez longtemps haha
Avis Hacker News
Cet article s’adresse aux utilisateurs de Linux sur desktop, mais je veux souligner que tmux révèle tout son potentiel sur MacBook avec iTerm2
Grâce à l’intégration de tmux dans iTerm2, tmux s’intègre de façon totalement naturelle à mon workflow
Si on configure
~/.ssh/configcomme ci-dessous, on peut toujours accéder facilement en ssh + tmux à un serveur de dev distant, même après avoir rallumé son MacBook ou changé de réseauGrâce à l’intégration entre iTerm2 et tmux, les onglets tmux distants et le tampon de défilement se comportent comme des onglets locaux, et en pratique on peut l’utiliser sans même connaître les commandes tmux
J’utilise Linux sur tout mon matériel personnel, et principalement un MacBook pour le travail ; tmux est vraiment utile parce qu’il me redonne le même environnement quelle que soit la plateforme
Sur Linux j’utilise Alacritty, mais sur macOS il y a toujours quelque chose qui ne fonctionne pas immédiatement à cause du réglage adéquat ou des différences autour des fenêtres et du défilement
Je ne veux pas perdre du temps avec ces différences entre OS, donc la combinaison tmux + iTerm2 est idéale pour obtenir une expérience presque identique à Linux
Le fait d’avoir un historique de scroll complètement séparé à l’intérieur de la session est aussi un avantage pour moi
Les critiques adressées à tmux relèvent plutôt, à mon avis, de problèmes qui concernent les développeurs de terminaux
Si le support est insuffisant, il suffit de passer à un terminal qui le gère mieux
J’utilise la combinaison mosh + screen
Je peux restaurer mes sessions même si le serveur redémarre, et elles ne se coupent pas quand je change de réseau
Référence : Immortal SSH Sessions
J’ai essayé tmux des dizaines de fois, mais ça ne m’a jamais vraiment plu, donc je suis toujours revenu à screen
Mais cette astuce me donne envie de retenter l’expérience
Avec la combinaison vim, tmux et iTerm2, je tombais souvent sur des problèmes de couleurs et de polices, donc j’ai fini par abandonner tmux en local
Cela survivait aux mises à jour, et le gain apporté par la persistance de session n’était pas si important
Si je pouvais régler uniquement les problèmes de police, je serais prêt à réessayer, mais je n’ai pas le temps pour l’instant
Je me demande s’il existe un terminal Linux qui propose une intégration avec tmux comparable à celle d’iTerm2
J’utilise encore GNU Screen, mais je serais prêt à redonner sa chance à tmux
Ce billet de blog m’a rappelé une fois de plus pourquoi j’utilise tmux
En voyant tout le travail que les gens doivent faire pour reproduire un workflow proche de tmux, je me dis qu’il vaut largement mieux utiliser tmux directement
Le copier-coller est parfois un peu moins pratique, mais ça m’est égal
La critique disant que « les multiplexeurs ajoutent une surcharge inutile » n’a pas d’importance sauf si l’on maintient la base de code
Les problèmes de copier-coller ne sont pas propres à tmux
Tous les programmes comme vim, qui redessinent eux-mêmes tout le terminal, peuvent provoquer cela
On peut résoudre facilement ce problème avec la séquence d’échappement terminal OSC52
Avec le petit script Python ci-dessous, on peut aussi envoyer directement dans le presse-papiers système des résultats de grep, etc.
tmux et nvim prennent déjà en charge OSC52, et c’est facile à réutiliser ailleurs
Pour info, j’ai déjà soumis une PR à tmux, et j’ai beaucoup apprécié la qualité des échanges avec le mainteneur Nick Marriott
Le code est bien structuré, et tmux s’en est trouvé amélioré
Je suis fatigué de ces discussions qui semblent inventer de faux problèmes
Les raisons avancées par l’auteur ne me convainquent pas, et cela me fait même douter de ses « plus de 7 ans d’expérience avec tmux »
J’ai découvert Tmux il y a quelques semaines, et j’ai été fasciné par la possibilité de scripter l’envoi de frappes vers un pane précis
Inspiré par un forum japonais, je me suis demandé si Claude Code (ci-après CC) pouvait interagir directement avec des scripts CLI nécessitant des interactions, et j’ai confirmé que c’était possible avec Tmux
J’ai donc créé un petit outil appelé claude-code-tools, qui permet à des agents CLI comme CC de créer des panes Tmux, d’y exécuter des scripts et même d’interagir avec eux en temps réel
C’est un peu comme une version terminal de Playwright ou Puppeteer
Lien GitHub vers claude-code-tools
Avec cette approche, CC peut servir à tester automatiquement des scripts CLI interactifs, à afficher une UI dans un autre pane puis à tester dans le navigateur avec Puppeteer MCP, à activer un débogueur et poser des points d’arrêt, à coordonner plusieurs agents, et à bien d’autres usages
Je me demande si les outils alternatifs à tmux pourraient offrir la même extensibilité
À noter que screen permet aussi d’envoyer programmatiquement des frappes à un pane avec la commande
stuffAvec cette approche, Claude Code peut contrôler en mode interactif différentes instances de CC comme Gemini CLI ou OpenCode
Cela permet un mode d’intégration différent des sous-agents traditionnels
Je me demande si un wrapper tmux-cli aide réellement à améliorer les résultats
De mon côté, il suffit de demander à Claude d’utiliser les commandes tmux existantes pour que ça fonctionne bien, donc je lui fais exécuter toutes les commandes dans une session tmux sans passer par Bash séparément
Si vous voulez faire ce genre de choses plus facilement au niveau du terminal, la fonction remote control de Kitty est aussi excellente
Présentation de Kitty Remote Control
Un terminal n’est au fond qu’un descripteur de fichier, donc des outils similaires comme script(1), expect(1) ou chat(8) existent depuis les années 80
tmux n’est pas indispensable
Le problème selon lequel les couleurs, etc., s’affichent mal dans tmux quand la variable TERM n’est pas correctement réglée est le même que pour tous les émulateurs et programmes de terminal
Sur les systèmes Unix et Linux, les concepts de TERM et de terminfo/termcap sont fondamentaux, donc une configuration correcte est indispensable
Ce n’est pas un problème propre à tmux
C’est dommage que l’auteur en fasse porter la faute à tmux
Je doute aussi que le problème de défilement vienne réellement de tmux ; tmux utilise l’alternate screen buffer, introduit pour clarifier la ligne de base du viewport et faciliter les déplacements du curseur
La plupart des terminaux modernes autorisent le scroll local même en mode alternate screen, si bien que cette propriété n’est plus vraiment respectée
La plupart des programmes ne se comportent pas comme prévu si leur configuration par défaut n’est pas correcte
Dans le cas de tmux, il est gênant que la raison ne saute pas immédiatement aux yeux, mais on ne voit pas clairement quelle serait la solution idéale, par exemple faut-il mettre 256colors par défaut ?
C’est vrai, mais utiliser tmux ajoute une couche supplémentaire à laquelle il faut faire attention
À l’intérieur de tmux, il faut utiliser un TERM propre à tmux, et à l’extérieur un TERM adapté à son terminal
Rien qu’en regardant la FAQ tmux, on voit que la plupart des problèmes d’affichage viennent d’un TERM mal configuré
La remarque selon laquelle « les multiplexeurs ajoutent une surcharge inutile » est justement l’une des raisons pour lesquelles je préfère tmux
À une époque où de plus en plus d’applications abandonnent le support termcap, tmux me permet encore d’exécuter des applis même sur de vieux terminaux comme mon VT520
Peu m’importe qu’un développeur de terminal déteste tmux
Au final, pour l’utilisateur, ce qui compte est que ça fonctionne, plus que l’élégance architecturale
Personnellement, je trouve d’ailleurs alacritty meilleur, même si j’utilise surtout Konsole
Je voulais juste dire que je t’envie d’avoir un VT520
Je cherche un VT525 depuis longtemps, mais c’est cher et les vendeurs sont presque tous à l’étranger
Je me suis toujours demandé si nosh realizer fonctionnait bien sur un vrai VT525
Même si tmux disparaissait, on pourrait translittérer autrement les applis ayant de subtiles incompatibilités TERM
Mon VT420 ne prend pas en charge le contrôle de flux matériel, donc je dois utiliser le contrôle de flux logiciel, et cette méthode est franchement peu compatible avec les applications de terminal modernes
GNU Screen constitue une très bonne solution, avec en plus de nombreuses autres fonctionnalités
J’ai beaucoup utilisé tmux sur des émulateurs modernes, mais sur les anciens terminaux il semble lui manquer cette fonction essentielle de contrôle de flux
Je suis d’accord sur le fait que tmux est utile pour gérer les applications qui ne prennent pas en charge termcap/terminfo
Je serais curieux de savoir pourquoi tu trouves alacritty meilleur
Sur du vieux matériel, il démarre lentement, il manque de fonctions pratiques comme les onglets, et même en benchmark il est derrière kitty/ghostty/konsole/foot
Malgré cela, il est intéressant de constater qu’il y a toujours des gens qui choisissent alacritty pour une raison ou une autre
Je compte toujours utiliser tmux
J’apprécie sa facilité pour gérer les sessions entre plusieurs projets et les restaurer après un redémarrage
Le copier-coller à la souris n’a jamais posé de problème avec tmux-yank
J’utilise le même environnement depuis des années
Avec la fonction
send-keysde tmux, j’ai mis en place une automatisation qui me permet, lors du refactoring de mes dotfiles, de mettre à jour facilement en même temps des alias ou fichiers de configuration dans plusieurs panes/sessions, puis de redémarrer nvimJ’ai résumé cette expérience dans un billet de blog et une vidéo
Pour moi, « you might not need tmux » ressemble au débat « you might not need browser tabs »
Si l’on n’a qu’une ou deux sessions de terminal ou pages web, on peut peut-être s’en passer, mais dès qu’on en gère davantage, l’organisation des fenêtres devient trop pénible et on finit par réimplémenter les mêmes fonctions
En ce moment, j’essaie simplement d’exploiter au maximum les fonctions de gestion de fenêtres de mon window manager
Au lieu d’utiliser les onglets du navigateur, les onglets du terminal ou tmux, je laisse le window manager s’occuper de la disposition des fenêtres, des onglets, des signets, etc., et cela ne me gêne pas
J’en viens presque à considérer comme une conviction que la gestion des onglets devrait relever du window manager et non des applications
Mon window manager peut disposer les fenêtres en tuiles ou regrouper des fenêtres superposées sous forme d’onglets
Ces onglets fonctionnent aussi bien avec la même application qu’avec des applications différentes
Les onglets de navigateur peuvent facilement être détachés ou fusionnés entre différentes fenêtres, alors que les onglets tmux sont moins flexibles sur ce point
Avec un bon window manager, on peut recombiner librement onglets et fenêtres
Dans ma configuration tmux, j’ai des onglets cliquables
La gestion de multiples fenêtres dans MS Windows (Alt Tab, Win Tab, etc.) est excellente
J’identifie chaque terminal avec une icône ou une couleur de fond différente, et l’OS prend déjà largement en charge la gestion des fenêtres
J’ai aussi utilisé Mac, mais sur ce point je n’ai jamais été aussi satisfait que sous Windows
Les aspects de tmux dont certains se plaignent, comme le scrollback du buffer, sont précisément ce qui me pousse à l’utiliser
Mon deuxième laptop est une vieille machine Debian dédiée au terminal, sans souris, donc je ne peux faire de copier-coller qu’avec tmux
Pour moi, tmux est irremplaçable
tmux capture-pane - | vim -est parfois plus pratique que la molette de la souris pour faire défilerLe camp suckless adopte une approche exactement opposée : lors de la conception de son terminal, il refuse délibérément d’implémenter des fonctions de type tmux
Référence : st.suckless.org/goals
J’espère que Kitty réussira, car il semble pouvoir porter l’avenir des émulateurs de terminal
Mais je ne peux pas utiliser Kitty pour le travail, et sans tmux je perdrais sessions, disposition des fenêtres, état, tampons de copie et historique de défilement, donc il est hors de question que j’abandonne tmux
Tant qu’il n’existera pas d’alternative convenable sur Windows, je continuerai à utiliser tmux pour le travail, même si j’utilise Kitty à côté
Mais au final, je suis revenu à la combinaison tmux + terminal par défaut
Comme cela fonctionne partout et que l’approche par composition d’outils dure plus longtemps, tmux reste encore la meilleure option à mes yeux