Une session tmux prend souvent sa forme en situation réelle: des panes changent de rôle, des fenêtres se regroupent, et des commandes sont corrigées, retirées ou conservées.
tmuxp devient utile quand cette structure se stabilise. Au lieu de figer la session trop tôt, construisez d’abord dans tmux, puis ne gardez que ce qui mérite d’être rejoué.
Projet tmuxp
Projet officiel: tmuxp/tmuxp
Workflow pratique
1. Démarrer une session tmux nommée
Créer ou rattacher une session tmux nommée. Le nom de session donne une cible stable pour se reconnecter, exporter et recharger.
$ tmux new-session -As sensorssensors est un nom d’exemple dans cet article; la même approche fonctionne pour toute session tmux à préserver.
2. Façonner la session en usage réel
Utilisez la session et ajustez-la volontairement: gardez les panes réellement utiles, redimensionnez pour la lisibilité, renommez les fenêtres quand cela aide, puis réaffectez les panes au fil du travail.
3. Exporter le layout validé
Quand le layout et les rĂ´les de panes sont assez stables, exportez la session en cours vers un workspace tmuxp.
$ tmuxp freeze sensors -o sensors.yaml
Important
tmuxp freeze exporte une définition de workspace réutilisable depuis la session en direct et conserve une base structurelle fiable pour le reload. Ce n’est pas un checkpoint complet du runtime shell ni de l’état des processus de longue durée. Les commandes exportées peuvent inclure de l’activité temporaire de session en direct, qui peut nécessiter un cleanup.
Un export freeze peut avoir la bonne structure, mais contenir des commandes inadaptées à un démarrage reproductible. Gardez la structure panes/fenêtres et réécrivez uniquement la politique de replay.
Dans ce sensors.yaml mis Ă jour, la politique de replay devient explicite:
enter: falseest appliqué aux panes d’action pour précharger les commandes sans exécution automatique.- Les deux panes
watchrestent en auto-run car ce sont des panes d’observation. start_directory: /workspacestabilise le contexte, etfocus: 'true'atterrit sur une pane d’action staged.
Le YAML gelé reflète ce qui était actif au moment du freeze. C’est utile pour la structure, mais souvent trop bruité pour un démarrage reproductible.
4. Affiner le replay de façon optionnelle
L’affinage est optionnel. Si le comportement au reload est déjà correct, le fichier freeze suffit.
Quand un cleanup est nécessaire, traitez-le comme une phase d’édition explicite après export: conservez la structure, puis réécrivez seulement le comportement de replay.
- Remplacez les commandes ponctuelles capturées en live par des commandes de démarrage intentionnelles, et utilisez les multi-line commands quand la lisibilité compte.
- Gardez les panes manuelles explicites avec
null/blank/pane. - Préchargez les commandes avec
enter: falsequand elles doivent être visibles sans auto-run. - Déplacez le setup partagé vers
shell_command_before(aussi ici).
Vérifier avant usage régulier
Avant usage régulier, faites un reload depuis YAML et vérifiez que le comportement correspond au fichier.
$ tmux has-session -t sensors 2>/dev/null && tmux kill-session -t sensors; tmuxp load ./sensors.yamlVérifiez que le reload passe, que la structure de panes correspond au layout gelé, et que le comportement des commandes suit la politique de replay définie. Sinon, ajustez le YAML concerné puis relancez.
Travaillez en direct jusqu’à stabiliser le layout, sauvegardez-le avec tmuxp freeze 🧊, puis affinez le YAML seulement là où la réutilisation crée encore de la friction.
