Liquidation de prompt

Malgré la mode actuelle autour de l'intelligence artificielle, ce n'est pas de ce genre de prompts dont il va être question. Je vais parler ce qu'on appelle parfois en français « invite de commande », qui est ce qu'un ordinateur affiche pour indiquer qu'il est prêt à recevoir une nouvelle commande et inviter l'utilisateur à l'entrer.

Comme je ne comprends pas très bien comment « invite » pourrait être une inflexion correcte du verbe « inviter », je ne peux qu'y voir un affreux anglicisme, et je préfère l'écrire « invit' », comme raccourci d'« invitation ».

Il s'agit historiquement d'un élément clé des interfaces en mode texte, parce qu'il n'y avait pas tellement d'autre façon d'indiquer si l'ordinateur est occupé ou en attente, surtout avec la tradition Unix de ne rien afficher du tout quand aucune erreur ne se produit.

Si je vais effectivement de parler des prompts en mode texte de mes shells, le même concept se retrouve dans toutes les interfaces qui n'ont pas de canal dédié pour communiquer cet état. Par exemple, certains assistants vocaux indiquent leur activation avec un signal sonore, et c'est effectivement un prompt qui indique que l'activation a bien eu lieu et que l'utilisateur peut dicter sa commande.

Tant qu'il s'agit d'indiquer un état occupé ou disponible, un simple caractère, comme >, suffit largement. Il y a cependant d'autres caractéristiques de l'état courant qu'il peut être intéressant d'avoir en tête pour choisir une commande, au point d'intégrer cette information dans le prompt.

Par exemple, les plus anciens expérimentés d'entre nous se souviennent peut-être du C:\> de DOS, on y retrouve le > traditionnel d'invitation, et C:\ est le répertoire courant, dans lequel tous les fichiers sont lus ou écrits (sauf indication contraire explicite). C'est plutôt important pour s'y retrouver dans ses fichiers.

Il y a donc un équilibre à trouver entre la quantité d'informations qu'on peut afficher, et la place que ces informations occupent. Comme le prompt est présenté avant chaque commande, il est souvent répété et une abondance d'informations peut occuper une place précise qui serait mieux utilisée pour les résultats des commandes.

J'écris ce billet à l'occasion du changement de mon prompt, dans la suite des vents du changement qui soufflent sur mon interface depuis des mois. Mon nouveau prompt est tellement dense qu'il me faut une documentation pour m'en servir, au moins le temps d'en prendre l'habitude, et tant qu'à faire autant la publier, au cas improbable où quelqu'un d'autre que moi s'y intéresserait.

Et comme j'ai fait le tour de mon ancien prompt pour vérifier que je n'avais rien perdu en route, j'en profite pour le documenter aussi, et offrir à moi-du-futur un enregistrement de mon quotidien textuel de 2009 à 2023.

Le reste de ce billet va donc être profondément technique, comme je le signale avec le tag Geek. Mon lectorat peu familier avec les interfaces en mode texte peut donc sereinement arrêter la lecture ici, la suite leur sera probablement peu accessible.

L'ancien prompt

Je sais que j'écris trop, alors je vais commencer par les screenshots :

Circonstances historiques

J'ai détaillé l'histoire de mon environnement graphique dans le billet Ricing, mais je suis passée un peu vite sur les débuts, parce que je les ai largement oubliés.

Je me souviens que ma grosse perte de données la plus récente date de juin 2008, quand l'alimentation de Gomorrhe est tombée en panne et que Dedibox m'a confié Yomi en remplacement, sans aller chercher les disques durs.

À cette époque, j'avais une certaine curiosité envers les BSD en général, et j'avais déjà conclu que FreeBSD était le plus approprié pour mes débuts. Se retrouver brutalement avec un serveur dédié vide a été l'occasion de faire ma première installation BSDesque.

Comme j'ai plutôt bien aimé, j'ai aussi installé FreeBSD sur la machine vide suivante que j'ai eue entre les mains, qui se trouvait être mon poste de travail professionnel. C'était le 7 janvier 2009.

Sous l'influence des gens de #freebsd-fr, que j'étais voir pour chercher de l'aide sur des petits soucis techniques, j'ai essayé zsh le 18 janvier 2009, et j'ai vite été conquise.

C'est peut-être un peu injuste de comparer un bash par défaut avec un zsh configuré aux petits ognons, mais c'est un peu comme ça que ça s'est passé.

Ce prompt historique, qui m'a tenu plus de 15 ans, a été ma première personnalisation de prompt.

Je n'ai plus aucun souvenir d'où je l'ai pioché, et je n'en retrouve pas de trace numérique non plus. J'ai le vague souvenir qu'à l'origine il était rectangulaire, avec des coins à droite aussi, et encore plus vague qu'il y avait l'heure en bas à droite, en dessous du path, mais je confonds peut-être avec un autre prompt que je n'ai finalement pas choisi. Si ces souvenirs sont à peu près bons, j'ai viré ça parce que ça interagissait mal avec mon terminal, à cause de la ligne pleine à craquer ou des redimensionnements. Et je ne voyais pas l'intérêt d'avoir l'heure dans le prompt alors que j'ai une horloge ailleurs sur l'écran, et je n'aimais pas que l'entrée de la commande la fasse disparaitre inopinément.

Donc j'ai pris ce prompt de je‐ne‐sais‐plus‐où, j'ai viré l'éventuelle heure et les coins de droite, et j'ai utilisé ça pendant quinze ans presque sans aucun changement.

« Presque », parce que les lignes étaient tracées avec l'alt charset façon VT100, et j'ai fini par les remplacer des caractères unicode.

Architecture de l'ancien prompt

La caractéristique principale de ce prompt est de tenir sur deux lignes.

Il me semble que c'est un compromis assez discuté : d'un côté tout mettre sur une ligne prend moins de place, surtout avant de commencer à taper une commande ; d'un autre côté la répartition sur deux lignes permet de mieux ranger les données.

Ce qui me plaît le plus dans le fait d'avoir deux lignes, c'est la séparation visuelle entre les différentes commandes, très utile quand on essaye de se déplacer rapidement dans l'historique. Et c'est encore mieux depuis que les lignes sont en Unicode, ça permet d'utiliser la recherche de texte pour remonter au début de la commande ou naviguer de commande en commande.

Donc les lignes sont pas juste là pour l'esthétique, leur fonction structurale est capitale pour moi.

Et c'est peut-être juste ça qui m'a fait adopter ce prompt, le reste est assez standard.

Sur cette structure, il y a donc quatre points sur lesquels poser des informations, à chaque extrémité de chaque ligne. Comme dit dans l'historique, je ne suis pas sûre de ce qu'il y avait dans le coin inférieur droit (c'est-à-dire à la fin de la ligne d'entrée de commande), mais il n'y a rien là dans ce que je considère comme mon prompt historique.

Il reste donc trois blocs : la gauche et la droite de la ligne de séparation, et l'espace juste avant la fin du prompt sur la ligne où j'entre la commande.

Il n'y a pas de sémantique particulière dans les couleurs, leur choix est presque purement esthétique, et hérité de là où j'ai pioché ce prompt. La structure est cyan et bleue, les blocs sont respectivement vert, magenta, et blanc brillant ; et certaines informations importantes sont appuyées par de la vidéo inverse ou du rouge.

Caractéristiques du shell (en haut à gauche)

Exemple : (nat@tsuiraku:pts/9)

Le bloc sur la gauche de la ligne de statut contient toutes les informations qui restent constantes pour toute la durée de vie du shell :

• le nom d'utilisateur (nat ou ROOT dans les captures),
• le nom de la machine (Tsuiraku dans les captures),
• la ligne série sur lequel le shell est connecté (/dev/pts/1 et /dev/pts/9 dans les captures).

Pour insister sur le danger des comptes privilégiés, au lieu d'afficher simplement root, le nom d'utilisateur est capitalisé et inversé. D'expérience ça attire bien l'œil et c'est très utile pour éviter les méprises.

Répertoire courant (en haut à droite)

Exemple : (/tmp)

Ce n'est pas pour rien que le répertoire courant se trouve dans presque tous les prompts, c'est une partie très importante du contexte dans lequel les commandes s'exécutent.

Comme le chemin complet peut être particulièrement long, et que mes terminaux sont relativement étroits, il arrive que ça ne rentre pas dans la largeur d'une ligne. J'ai fait exprès de mettre un cas comme ça dans les captures, pour montrer que le chemin est juste tronqué à gauche, avec une ellipse pour indiquer cette troncature.

Les erreurs et l'invit' (en bas à gauche)

Exemple : 130:INT:%

C'est la seule partie vraiment variable de ce prompt : le code d'erreur de la commande précédente n'est affiché que s'il est non-nul.

Voici en détail tout ce qui peut être affiché :

• le code de retour numérique (1 et 130 dans les captures),
• le signal correspondant (INT dans la capture),
• le caractère de fin d'invit' (% ou # dans les captures).

C'est un peu contre-intuitif d'avoir le code d'erreur de la commande précédente après le séparateur plutôt qu'avant, mais l'avoir juste à côté du curseur, où on est presque obligé de poser les yeux, diminue le risque de le rater. Je trouve que c'est un bon compromis.

Le caractère de fin d'invit' % a l'air d'être une tradition de zsh, par rapport au $ qui semble plus courant dans les autres shells Unix. Le caractère # semble être une tradition Unix pour indiquer un compte privilégié, et la couleur rouge appuie ce statut, mais c'est nettement moins efficace sur moi que le nom de compte en couleurs inversées.

Les insatisfactions

Pendant que j'hésitais à changer de prompt, j'ai regardé de plus près cet ancien prompt en remettant à peu près tout en cause, pour finalement en garder à peu près tout.

Voici les points majeurs que j'aurais de toute façon changés suite à cette analyse, même si j'avais laissé tomber l'envie de nouveauté :

• Les trucs avant le caractère d'invit' sont pénibles pour copier-coller une commande avec sa sortie quand je veux faire une sélection rectangulaire (typiquement parce que le terminal est coupé verticalement ou parce qu'il y a des informations inutiles ou sensibles à droite, ou parce que les retours à la ligne sont mal gérés par le terminal), ce qui n'est pas si rare que ça. Le code d'erreur a assez de valeur pour rester là, mais pas les symboles structurels.

• La ligne série ne me sert strictement à rien, j'ai remarqué une fois que j'étais sur un tty au lieu d'un pty, mais je n'ai que faire que cette information qui mange une place précieuse.

• Le répertoire courant en magenta est inutilement criard. Je ne le voyais plus avec l'habitude, mais il a suffi de jouer un peu avec d'autres couleurs pour se rendre compte de l'accentuation que portent le rouge et le magenta. Un répertoire courant qui n'a rien de particulier mérite des couleurs plus neutres.

Le nouveau prompt

Mon nouveau prompt est basé Liquid Prompt et rangé dans un script arhci-moche dont j'ai honte, mais je ne vais pas vous le décrire avant d'avoir montré une capture d'écran et raconté comment j'en suis arrivée là.

Les vents du changement

L'histoire commence avec une dépêche LinuxFr sur la comparaison de systèmes de prompt, et la conférence correspondance à Capitole du Libre.

Je savais déjà qu'il existe des prompts super avancés, mais ma réaction a toujours été que je n'ai pas besoin de ça. J'ai profité de cette dépêche et de cette conférence pour me mettre à jour sur l'état de l'art, et je l'ai pris avec l'esprit ouvert, mais j'en suis quand même sortie avec l'impression de ne pas avoir besoin de ça.

Comme je l'ai déjà dit plusieurs fois, mes lignes de commandes passent souvent à travers un réseau, et l'état d'une machine distante est une question de monitoring qui n'a rien à faire dans mon prompt, tandis que l'état d'une machine locale relève de mon interface graphique et n'a rien à faire dans mon prompt.

Après avoir enlevé tout ça, il ne reste guère que des informations sur l'environnement dans le shell ou le répertoire courant, comme le venv actif ou l'état du dépôt qui contient le répertoire courant.

Je n'utilise pas du tout les premiers, et j'ai l'habitude de gérer mes dépôts avec des commandes. Je fais sans depuis plus d'une décennie, et ça ne m'a jamais manqué, donc je n'ai pas besoin de tout ça.

Malgré tout, dans les semaines qui ont suivi j'ai regardé avec un œil différent ma façon de travailler, et j'ai vu que j'écris quand même souvent git status, pour en tirer des informations que d'aucuns ont toujours sous les yeux dans leur prompt.

Évidemment, un git status est beaucoup plus riche qu'un prompt de taille raisonnable, et j'ai souvent besoin de cette richesse. Il y a cependant un bon nombre de git status que je tape juste pour vérifier que la branche courante est bien celle que je crois, ou que j'ai bien commit tous les fichiers que j'ai modifiés, et tout ça peut se trouver directement dans un prompt un peu évolué.

Donc j'ai décidé de donner une chance à Liquid Prompt, qui était celui qui me tentait le plus dans ce comparatif.

Après y avoir investi beaucoup plus de temps que je pensais (plus de cinq heures), je suis arrivée à une configuration qui me plaisait à peu près autant que mon ancien prompt, les informations de dépôt en plus.

Au fil du temps, je me suis mise à apprécier de plus en plus l'accessibilité des informations supplémentaires, et j'y trouve aujourd'hui un vrai bénéfice par rapport au prompt historique, au point de le déployer assez rapidement sur toutes mes machines.

Je suis cependant encore loin d'utiliser tout son potentiel, parce que la densité d'information est telle qu'il faut un lexique pour s'en sortir. Ce billet est ma façon de documenter et d'apprendre ce lexique.

Architecture du nouveau prompt

J'ai gardé le même esprit que l'ancien prompt, parce qu'il me plaisait beaucoup, et pour minimiser le risque que je n'aime pas juste parce que c'est différent. J'ai évidemment corrigé au passage les insatisfactions que j'avais.

Donc je garde mes trois blocs habituels, et j'en ajoute un quatrième pour les informations du dépôt en cours, s'il y en a un :

• état du shell,
• répertoire courant,
• informations sur la commande précédente,
• dépôt courant.

La répartition en principe est respectivement en haut à gauche, en haut à droite, en bas à gauche, et en bas à droite. Et en dessous de tout ça, j'ai uniquement le caractère d'invit', tout seul sur sa ligne.

Comme les deux derniers blocs ne sont pas forcément présents, quand il n'y a rien de particulier à la commande précédente et il n'y a pas de dépôt courant, j'ai la forme habituelle sans le coin inférieur gauche.

Quand un seul des deux blocs optionnels est présent, il ajoute une ligne avec son information à gauche. Ça fait que le dépôt courant peut se retrouver à gauche ou à droite, suivant qu'il y a des choses à dire sur la commande précédente ou non. En général je préfère que les informations soient toujours au même endroit, mais j'aime encore moins le vide en bas à gauche, je ne sais pas trop pourquoi.

Comme ça vient facilement avec Liquid Prompt, j'en profite pour passer à la ligne quand deux informations côte à côte sont trop larges pour rentrer sur la même ligne.

Le chemin courant passe à la ligne en restant collé à droite, et si une ligne pour lui tout seul ne suffit pas alors seulement il est tronqué au milieu, où Liquid Prompt trouve que c'est le plus opportun, avec une ellipse unicode pour l'indiquer.

Si les informations sur la commande précédente et le dépôt courant ne tienne pas côte à côte, ils sont chacun à droite de leur ligne ; ça n'est pas plus incohérent que le dépôt qui peut être à droite ou à gauche, et ça évite le trou disgracieux juste au-dessus de mon curseur.

Je vais détailler les quatre blocs avec les informations qu'ils contiennent, mais c'est plus le résultat de la lecture de la documentation et du code que de l'expérience personnelle.

État du shell

Exemple : (nat@tsuiraku:1&/2z)

Dans la lignée de mon ancien prompt, il s'agit surtout du nom d'utilisateur et de la machine. Je ne me limite cependant pas à ces informations constantes, j'ajoute d'autres détails sur l'état global du shell.

• Les parenthèses qui entourent le bloc sont :
  • bleues dans un multiplexeur (genre tmux ou screen),
  • grises dans un shell direct.
• Le nom d'utilisateur,
  • en jaune et en gras pour un utilisateur privilégié,
  • en gris le reste du temps.
• Une arobase (@),
  • en verte dans une interface graphique,
  • en jaune sans interface graphique.
• Le nom de la machine,
  • de la couleur de l'arrobase pour la machine locale,
  • en bleu par une connexion SSH,
  • en rouge par une connexion telnet,
  • en jaune et en gras dans su.
• Le niveau d'imbrication du shell, en vert.
• Le nombre de jobs qui tournent en arrière plan, suivi de &, en jaune.
• Le nombre de jobs en pause, suivi de z, en jaune.

Répertoire courant

Exemple : (~/code/st/src)

L'information la plus importante dans ce bloc est évidemment le répertoire courant lui-même, et il n'y a pas grand-chose de plus.

J'ai ajouté le nombre de répertoires stockés dans la pile (pushd et popd), avec des parenthèses ouvrantes (comme si les répertoires empilés étaient en dessous et décalés d'un cran) s'il n'y en a pas beaucoup, ou avec un nombre en jaune sinon.

Le répertoire courant lui-même est en vert, avec le répertoire le plus haut contenant un dépôt qui est marché en bleu.

Informations sur la commande précédente

Exemple : 130(interrupted) 2s 11:16:51

Comme dans mon ancien prompt, il s'agit surtout du code d'erreur renvoyé par la commande précédente, et son interprétation s'il s'agit d'un signal. J'en ai profité pour ajouter le temps qu'a duré la commande, si ça dure un peu, parce qu'il m'est arrivé plusieurs fois de regretter ne pas avoir un time sur des commandes inopinément longues.

Voici la liste complète des éléments de ce bloc :

• le code de retour numérique, en magenta, s'il est non-nul,
• l'interprétation du code, entre parenthèses, en magenta,
• la durée d'exécution, en jaune, si elle a pris plus de 2 s,
• l'heure à la fin de l'exécution, en bleu, si la durée est affichée.

J'utilise l'interprétation livrée avec Liquid Prompt, qui donne (interrupted) au lieu de INT. Comme cette interprétation va plus loin que simplement les signaux, je l'accepte pour l'instant ; peut-être qu'un jour je me motiverai à revenir au code basique des signaux.

J'ai ajouté l'heure de fin d'exécution des commandes longues, parce qu'il y a de la place qui ne sert pas vraiment, et parce que ça m'est parfois utile pour retrouver l'heure de départ de la commande.

Information sur le dépôt

Exemple : git master(+25/-25,-5)+

C'est la principale nouveauté de ce nouveau prompt, et comme c'est encore à l'essai je ne vais pas plus loin que les sorties de _lp_find_vcs et _lp_vcs_details_color.

Voici donc le contenu de ce bloc :

• le type de SCM, en toutes lettres, genre git ou fossil, en gris ;
• le checkout courant, genre nom de branche ou de bookmark ou de tag, et à défaut le début du hash,
  • en rouge s'il y a des changements locaux,
  • en rouge et en gras quand on est en retard sur upstream (il faut pull),
  • en jaune quand on est en avance sur upstream (il faudrait push),
  • en vert autrement ;
• le nombre de lignes en plus et moins par rapport au checkout, en magenta ;
• le nombre de commits en avance (en jaune) et en retard (en rouge) par rapport à upstream ;
• le symbole + en jaune s'il y a des choses dans le stash ;
• le symbole * en rouge s'il y a des fichiers non-suivis ;
• l'éventuel état particulier du dépôt (résolution de conflit de merge, en cours de rebase, etc) en rouge ;
• l'éventuel état particulier d'upstream.

Conclusion

J'ai une certaine réticence à appeler cette section « verdict », parce qu'habituellement je donne sur ce weblog des impressions à très long terme, et les deux mois que j'ai passés avec ce nouveau prompt me donnent l'impression que mon avis est encore « à chaud ».

Comme écrit plus haut, je suis de plus en plus contente de ce nouveau prompt, au fur et à mesure je prends conscience des informations qu'il fournit.

Je ne suis pas encore convaincue de l'intérêt de tous les détails qu'il transmet, mais comme j'ai été plusieurs fois contente d'en découvrir de nouvelles et comme je trouve la densité d'informations largement suffisante pour mon goût, je laisse tout le reste.

Une de mes principales craintes était le temps d'exécution de ce prompt, probablement parce que c'était un point longuement discuté dans la conférence initiale et auquel beaucoup de gens semblent accorder beaucoup d'importance. S'il y a bien un délai sensible dans l'acquisition des informations sur le dépôt courant, il est assez rare pour ne pas me gêner. Les autres fonctions sont suffisamment rapides pour ne causer aucune friction consciente, même sur mes machines les plus poussives.

Je manque encore de recul sur l'utilisation de ce prompt dans un shell privilégié. Je ne suis pas sûre que marquer l'utilisateur en jaune soit suffisant pour éviter les fausses manip', il faudra voir à l'usage. La marque des répertoires en jaune me marque beaucoup plus que l'utilisateur, et va peut-être suffire pour éviter les erreurs. Les informations de dépôt sont désactivées par défaut dans ces shells, il faudrait que je me pose pour faire une analyse de sécurité sérieuse pour voir si je l'active.

Je ne suis pas super-contente de la façon dont Liquid Prompt s'intègre à ma configuration. Pour l'instant j'ai mis le script intégral dans mon dépôt chezmoi, mais ça ne me plaît pas trop. Peut-être qu'un script en run_once_ serait plus opportun, mais ça suppose un accès internet et une stabilité upstream.

Enfin je ne peux pas échapper à la question de la rentabilité de ce changement. Je pense que sur un point de vue purement temporel, le temps que je gagne grâce à ce prompt ne rattrapera jamais le temps investi dans la configuration, même sans compter les sept heures de rédaction de ce billet. Le confort est plus difficile à quantifier, j'ai envie de croire que le gain de confort suffit à justifier les efforts dépensés, mais c'est loin d'être évident. J'en suis presque à me justifier en invoquant l'exercice mental de découvrir de nouvelles choses et secouer ses habitudes.

Ce sont les seules réserves que j'ai pour l'instant, ce qui est finalement assez léger.

Je suis globalement très contente de l'opération.

Commentaires

Pas de commentaire pour le moment.

Poster un commentaire

Nom ou pseudonyme :

Adresse e-mail (facultatif, ne sera pas publié) :

Site web (facultatif) :

Format de mise en forme : format historique Markdown restreint

Enregistrer ces informations dans un cookie

Commentaire (sera publié dans cette page, voir les conseils de mise en forme ci-dessous) :

Message personnel (ne sera pas publié) :

Mise en forme historique : pour mettre en valeur un mot ou un groupe de mot, tapez une étoile de part et d'autre, sans mettre d'espace entre l'étoile et le mot, comme ceci : *mise en valeur*. Pour insérer un lien, mettez le entre crochets, comme ceci : [http://instinctive.eu/].

Mise en forme markdown : voir le guide détaillé, en résumé c'est le Markdown traditionnel, sans HTML ni titres, mais avec les tables PHP-Markdown-Extra.

Attention : les balises HTML entrées dans les commentaires seront affichées telles quelles, et non pas interprétées.