URL: https://linuxfr.org/news/comparaison-critique-de-systemes-d-invite-de-commande
Title: Comparaison critique de systèmes d'invite de commande
Authors: nojhan
 Ysabeau 🧶 et gUI
Date: 2023年11月15日T21:24:52+01:00
License: CC By-SA
Tags: shell, prompt, ligne, commande, design et terminal
Score: 61
Cet article a été écrit à l’occasion de [l’imminence de la sortie de la version 2.2 de Liquid Prompt](https://github.com/liquidprompt/liquidprompt/releases/tag/v2.2.0-rc.1) et vous aurez l’occasion de pouvoir en discuter avec son auteur lors des journées [Toulouse Capitole du Libre](https://capitoledulibre.org/), qui proposera une conférence sur [Liquid Prompt : repenser en profondeur le design du prompt shell](https://cfp.capitoledulibre.org/cdl-2023/talk/KYLR9C/).
# TL;DR: résumé
Si vous utilisez la ligne de commande, vous gagneriez à utiliser un bon système d’invite de commande (« prompt ») au lieu de la configuration par défaut. Parmi les sept systèmes de prompt les plus connus, certains sont mieux conçus et d’autres prennent mieux en charge certaines fonctionnalités.
Mes principales conclusions sont les suivantes :
- Si vous recherchez le système qui offre la meilleure expérience globale à l’utilisateur, vous devriez probablement utiliser Liquid Prompt.
- Si la faible latence est plus importante pour vous que les fonctionnalités, vous devriez miser sur PowerLevel10k.
- Si vous êtes un développeur qui jongle en permanence avec plusieurs jeux d’outils, Starship semble être la meilleure option pour vous.
Cet article est divisé en deux parties principales : la première introduit le sujet et présente les principales évaluations ; la deuxième partie entre dans les détails des designs et des fonctionnalités. Enfin, la conclusion donne des conseils sur le choix d’un prompt et propose quelques idées sur l’avenir des systèmes de prompts.
----
----
# Introduction
Avertissement : je suis l’auteur original de Liquid Prompt. Au début, j’ai fait cette étude approfondie pour savoir si je devais continuer à m’intéresser à Liquid Prompt ou passer à un autre système. Je vais essayer d’expliquer ici pourquoi je pense toujours que c’est l’un des meilleurs systèmes de prompt du marché.
Tous les systèmes de prompt comparés ici sont de bons logiciels libres, je me concentrerai donc ici sur l’utilité de leurs fonctionnalités, plutôt que de m’attarder sur la qualité du code ou la facilité d’installation.
## Qu’est-ce qu’un prompt ?
Il existe deux types d’informaticien·ne·s : celleux qui utilisent la ligne de commande et celleux qui sont à la retraite. Même les développeurs qui adoptent des interfaces de développement très intégrées disposent d’une sorte de terminal dans certains panneaux de leur IDE. Qu’on le veuille ou non, l’interpréteur de commandes fait partie intégrante de la vie quotidienne de la plupart des personnes qui attendent de leur ordinateur qu’il travaille pour elles.
L’interpréteur de commandes (le « shell ») a accès à de nombreuses informations sur l’ordinateur. Et la plupart de ces informations concernent l’état actuel de l’environnement de travail, ce qui est du plus haut intérêt pour l’utilisateur. Cependant, par défaut, le shell n’affiche que très peu d’informations, à moins que vous ne les demandiez expressément. En outre, le seul endroit de l’écran disponible pour l’affichage permanent de quoi que ce soit est le prompt.
Le prompt est cette chaine de caractères affichée juste devant la ligne où vous tapez vos commandes. Dans la configuration par défaut la plus courante, elle n’affiche que trois informations : l’utilisateur, le nom d’hôte et le chemin d’accès `user@hostname:path $ `.
Mais il peut en afficher davantage ! C’est l’objectif des systèmes de prompt. Ces prompts (pour faire court) ajoutent en fait beaucoup d’informations à cette partie de la ligne de commande. Par exemple, la fonctionnalité la plus courante est d’afficher l’état du dépôt Git dans lequel se trouve l’utilisateur.
## Les concurrents
Comme c’est souvent le cas avec les logiciels destinés aux utilisateurs chevronnés, le marché est très fragmenté : il existe une tonne de prompts disponibles. Beaucoup de gens semblent aimer programmer leur prompt à partir de zéro et le déposer sur GitHub.
Dans le cadre de cet article, je n’ai pris en compte que sept prompts. Parmi les plus populaires, d’après le nombre d’articles de fans trouvés par Google et d’après les étoiles sur GitHub :
- [PowerLevel10k](https://github.com/romkatv/powerlevel10k), le plus populaire,
- [Starship](https://github.com/starship/starship), celui programmé en Rust, et [Spaceship](https://github.com/spaceship-prompt/spaceship-prompt), son origine (dans ce qui suit, les deux sont considérés comme un seul système, étant donné leur similarité, mais vous voudrez probablement utiliser Starship de toute façon),
- [Powerline](https://github.com/powerline/powerline), qui fait des lignes de statut,
- [Pure](https://github.com/sindresorhus/pure), le système minimal au succès surprenant,
- [Oh-My-Posh](https://ohmyposh.dev), le système portable,
- [Liquid Prompt](https://github.com/nojhan/liquidprompt), le plus ancien (historiquement parlant).
Il convient de noter que le nombre d’étoiles n’est pas nécessairement lié à l’âge du logiciel. Par exemple, Liquid Prompt a été lancé en 2010, tandis que Powerlevel* a été lancé en 2015 et Starship en 2019.
## Ce dont vous avez besoin, c’est du design de l’information
La raison d’être d’un prompt c’est qu’il est utile d’avoir un accès immédiat à l’état actuel du système. Le fait de voir un changement d’état à l’endroit même où l’utilisateur regarde habituellement est un très bon retour d’information sur ses actions. Mais, bien entendu, ce retour d’information ne doit pas entraver le travail de l’utilisateur.
Les états doivent être choisis et affichés en fonction de leur importance pour le travail de l’utilisateur. Plus précisément, un bon prompt est un prompt qui est :
- **focus** : il vise les états qui sont réellement utiles à l’utilisateur au cours d’une session de travail,
- **transparent** : il n’entraîne pas de friction avec le processus de travail de l’utilisateur,
- **ciblé** : il vise des états qui peuvent changer d’eux-mêmes ou être changés par l’utilisateur,
- **mesuré** : il tient compte du fait que certains états changent moins souvent que d’autres (et évite ainsi d’être une simple collection d’états qui ne changent que rarement),
- **accentué** : il rend plus visible le retour d’information concernant les changements d’état les plus importants, tout en ne polluant pas la visibilité des états stables/anecdotiques,
- **configurable** : il est facile d’adapter immédiatement l’affichage des informations, si nécessaire.
En d’autres termes, un bon système d’alerte doit être bien conçu.
Mon évaluation de la conception générale des candidats est résumée dans le tableau suivant :
| Prompt | Focus | Transparent | Ciblé | Mesuré | Accentué | Configurable |
| ------------- | ------- | -------- | ------ | -------- | ----------- | ------------ |
| Liquid Prompt | 🌟🌟🌟 | ⭐⭐ | ⭐⭐ | 🌟🌟🌟 | 🌟🌟🌟 | 🌟🌟🌟 |
| PowerLevel10k | ⭐⭐ | 🌟🌟🌟 | ⭐⭐ | ⭐⭐ | ⭐⭐ | ⭐⭐ |
| Oh-My-Posh | ⭐⭐ | ⭐⭐ | ⭐⭐ | ⭐⭐ | ⭐ | ⭐⭐ |
| Pure | ⭐⭐ | ⭐⭐ | ⭐⭐ | ⭐⭐ | ⭐ | ⭐⭐ |
| *ship | ⭐ | ⭐⭐ | ⭐ | ⭐ | ⭐ | ⭐⭐ |
| Powerline | ⭐ | ⭐⭐ | ⭐ | ⭐ | ⭐ | ⭐ |
La section « design » de l’article (voir ci-dessous) explique plus en détail pourquoi.
## Toutes les fonctionnalités ne naissent pas égales
Quels types de fonctionnalités nos six candidats proposent-ils ? On peut considérer six catégories (de la plus importante à la moins importante) :
- **l’essentiel du shell** : les fonctionnalités que l’on trouve habituellement dans un prompt classique (chemin, utilisateur, codes de sortie...), qui sont utiles au quotidien (tâches, capteurs, intégration de multiplexeurs...), ou qui sont généralement considérées comme importantes (thèmes...).
- la **gestion de version** : Git, Mercurial, etc.
- **environnements** : détection de configuration dynamique (virtual env, variables shell, conteneurs...).
- **versions des outils** : version actuelle d’outils spécifiques (langages de programmation, chaines de construction, outils...).
- **fonctions diverses** : fonctions liées au shell considérées comme moins importantes (réseau, titre du terminal, liens hypertextes...).
- **services** : services fonctionnant en permanence, en ligne ou sur la machine (musique, météo...).
Ces catégories sont délimitées en fonction de l’utilisation principale du terminal :
- Les fonctionnalités de la catégorie « l’essentiel du shell » sont celles dont vous aurez le plus souvent besoin, quoi que vous fassiez dans votre terminal.
- Si vous êtes programmeur, vous porterez une attention particulière aux catégories *gestion de version* et *environnements*.
- Si vous êtes développeur, la catégorie *version des outils* vous intéressera également.
- Si vous faites de l’administration système, la catégorie *divers* peut contenir des fonctionnalités marginalement intéressantes.
- Si vous avez besoin de fonctionnalités dans la catégorie des services, vous avez probablement mal compris ce qu’est une interface de ligne de commande, ou vous recherchez une barre d’état (ce qu’un système de prompt peut être).
Mon évaluation de la prise en charge globale de chaque ensemble de fonctionnalités est résumée dans le tableau suivant :
| Prompt | Essentiels | Gestion de version | Environnements | Versions d’outils | Divers | Services |
| ------------- | ---------- | --------------- | ------------ | -------- | ------ | -------- |
| Liquid Prompt | 🌟🌟🌟 | 🌟🌟🌟 | 🌟🌟🌟 | ⭐ | ⭐⭐ | _ |
| *ship | ⭐⭐ | ⭐⭐ | 🌟🌟🌟 | 🌟🌟🌟 | ⭐ | _ |
| PowerLevel10k | ⭐⭐ | ⭐ | 🌟🌟🌟 | ⭐⭐ | ⭐⭐ | ⭐ |
| Oh-My-Posh | ⭐ | ⭐⭐ | ⭐ | ⭐⭐ | ⭐ | ⭐⭐ |
| Powerline | ⭐ | ⭐ | ⭐ | _ | ⭐⭐ | 🌟🌟🌟 |
| Pure | ⭐ | ⭐ | _ | _ | _ | _ |
La section « fonctionnalités » ci-dessous explique en détail comment certains prompts prennent en charge certaines de ces catégories.
# Design
Chaque système de prompt possède une culture sous-jacente, née de son histoire, qui transparait dans sa conception.
Par exemple, Powerline a eu un impact considérable sur l’adoption de caractères supplémentaires dans les polices « patchées ». Liquid Prompt a ciblé, dès le début, des caractéristiques proches du shell lui-même, tout en mettant l’accent sur le design. D’un autre côté, PowerLevel10k a été conçu pour être aussi rapide que possible. Étonnamment, Starship a également commencé avec la promesse d’être rapide, bien qu’il ne se rapproche même pas de PowerLevel10k (un bon exemple de la façon dont l’impact des langages est surestimé). Il rassemble cependant une grande communauté, qui à son tour fournit des tonnes d’outils de support. A titre de contre-exemple, Pure a démarré sur la promesse d’être ascétique en termes de fonctionnalités, et s’en est tenu à cette idée.
## Si vous vous sentez sexy, vous avez l’air sexy
En ce qui concerne le design, les prompts candidats peuvent être répartis en trois catégories :
- ceux qui soutiennent que le plus simple est le mieux (Pure et *ship),
- ceux qui aiment le look classique des « chevrons » (Powerline et Oh-My-Posh),
- ceux qui accordent une attention particulière au design (Liquid Prompt et PowerLevel10k).
L’équipe de Pure, par exemple, affirme très clairement qu’il est « joli et minimal ». Et par joli, elle entend « livré avec le parfait caractère de prompt » (sic, c’est « ❯ ») et utilise des couleurs pastel. Son aspect par défaut est assez clairement partagé avec Starship, même s’il permet de configurer certains thèmes en utilisant également le look chevrons. Dans la documentation de cette catégorie de design de prompts, il n’y a pas beaucoup d’explications sur la raison pour laquelle les choses sont affichées (ou non).
La deuxième catégorie suit plus ou moins la même philosophie, en pensant seulement que ce qui est joli, c’est d’avoir un arrière-plan coloré au lieu d’un avant-plan, d’utiliser une police de caractères patchée pour séparer joliment les segments, et d’utiliser des icônes partout.
Bien entendu, vous trouverez des systèmes permettant une certaine configuration des icônes ou des couleurs, afin de reproduire l’un ou l’autre style (Starship et Oh-My-Posh proposent des thèmes dans les deux styles, Liquid Prompt et PowerLevel10k ont des thèmes reproduisant les deux, fonctionnalités comprises).
La dernière catégorie, cependant, va plus loin dans les détails lorsqu’il s’agit d’expliquer pourquoi elle montre les choses de telle ou telle manière, et permet plus généralement un ensemble plus varié de thèmes.
PowerLevel10k va jusqu’à fournir un assistant de configuration pour construire le thème que vous préférez, en combinant plusieurs caractéristiques (nombre de lignes, caractère de séparation, etc.) Cependant, en dehors des capacités techniques impressionnantes, l’approche globale de la conception consiste à afficher ce qui doit être affiché sous forme de segments colorés flashy avec des icônes.
Liquid Prompt fournit des thèmes prêts à l’emploi et dispose de l’ensemble le plus diversifié. Certains de ses thèmes n’ont pas d’équivalent chez les autres systèmes, et changent beaucoup de la « série de segments » de tous les autres prompts.
## Un segment pour les gouverner tous
Un exemple intéressant de l’importance de l’approche de design est la façon dont Powerline et Liquid Prompt indiquent à l’utilisateur qu’il se trouve dans une session multiplexée (ce sont les deux seuls à disposer de cette fonctionnalité). Les multiplexeurs de terminaux sont des systèmes qui permettent d’avoir plusieurs sessions permanentes sur une machine, et de les détacher/attacher à volonté. Les plus connus sont screen et tmux.
Powerline affichera un segment coloré indiquant le nombre de clients tmux attachés à la session. Liquid Prompt a divisé son support en deux informations différentes : il affichera d’abord le nombre de sessions détachées, et colorera ensuite les crochets entourant le noyau de l’invite (nom d’utilisateur, hôte, chemin) s’il se trouve actuellement dans une session multiplexeur. L’indice visuel est subtil, mais si l’on y réfléchit, il est logique, car c’est « autour » de ce qui change avec la connexion. Il n’est pas nécessaire d’utiliser beaucoup d’espace pour rappeler à l’utilisateur cette information, qui sera constante au cours d’une session de travail.
Un autre exemple est la façon dont Starship et Liquid Prompt indiquent que sudo est actif. Starship affichera une icône (d’un assistant), tandis que Liquid Prompt changera la couleur de la marque d’invite, près de l’endroit où l’utilisateur tape des commandes, puisque les informations d’identification sudo peuvent avoir un impact considérable sur leur effet.
Le même type de différence se produit lors d’une connexion SSH : Starship affiche une autre icône, à côté du nom d’hôte. Liquid Prompt affiche le nom d’hôte avec sa propre couleur. Les deux peuvent être configurés pour n’afficher le nom d’hôte que lors d’une connexion via SSH. Oh-My-Posh affiche un segment avec une icône, et PowerLevel10k affiche à la fois le nom d’utilisateur et le nom d’hôte sous SSH, mais n’indique pas si l’utilisateur a été commuté localement, comme les autres.
La même approche s’applique à l’affichage des droits d’écriture ou du support X11 : Liquid Prompt change la couleur d’un caractère existant, tandis que les autres prompts ont tendance à ajouter un nouveau segment/une nouvelle icône.
Vous pouvez commencer à voir la tendance ici : la plupart des prompts ont été conçues avec l’idée qu’un état atomique doit être ajouté à la liste des états, ou non. En d’autres termes, ils ont tendance à ajouter un nouveau segment (et/ou une nouvelle icône) à la liste des segments. Liquid Prompt est peut-être le seul à avoir réfléchi à l’idée de maximiser la réutilisation des indices visuels et à les positionner avec précaution.
Essentiellement, la plupart des systèmes de prompts donnent la priorité à la question « saviez-vous que ? » (par exemple, « saviez-vous que vous avez la version 3.14 de Python ? ») tandis que Liquid Prompt donne la priorité à la question « vous devriez noter que » (par exemple, « vous devriez noter qu’il est temps de git pull »).
## La force réside dans la diversité, pas dans la similitude
Bien entendu, la plupart des systèmes de prompts ont en commun le fait que de nombreux éléments sont configurables. Un utilisateur peut réorganiser ce qui est affiché et changer complètement le *look and feel* de son message. C’est flagrant quand on regarde la diversité des thèmes compatibles.
Ici, Oh-My-Posh a fait beaucoup d’efforts pour promouvoir un très grand nombre de thèmes. En plus des prompts *ship, ils utilisent un langage de configuration déclaratif qui prétend être le moyen le plus simple d’assembler un nouveau thème.
Je vois deux problèmes à cette idée, qui semble être très répandue parmi les informaticiens, même loin de la configuration des invites (pensez aux systèmes de construction, par exemple) :
1. la simplicité ne passe pas à l’échelle,
2. elle introduit trop de contraintes et limite l’innovation.
### La simplicité ne passe pas à l’échelle
Le premier problème est relativement évident si vous essayez d’interpréter une configuration de prompt complète, par exemple cette configuration aléatoire de [Oh-My-Posh/atomicBit](https://github.com/JanDeDobbeleer/oh-my-posh/blob/main/themes/atomicBit.omp.json) :
```
<#ffffff>[</strong>{{ .HEAD }}{{ if .Staging.Changed }}<#00aa00> \u25cf {{ .Staging.String }}</strong>{{ end }}{{ if .Working.Changed }}<#d75f00> \u25cf {{ .Working.String }}</strong>{{ end }}<#ffffff>]-</strong>"
```
Je ne fais même pas de sélection ; j’ai choisi celui-ci parce qu’il est en fait plus simple que le modèle par défaut. Que fait-elle en réalité ? Je ne suis pas sûr de vouloir faire les efforts nécessaires pour le comprendre. Par contre, je peux très bien voir l’intérêt de faire la même chose en script shell, avec des instructions if/then communément comprises, au lieu d’une soupe de parenthèses en notation polonaise inversée.
Je pense que, dans Liquid Prompt, cela ressemblerait à (non testé, juste ici pour donner une idée) :
```
 LP_COLOR_CHANGES=$GREEN
 LP_COLOR_COMMITS=$MAGENTA
 
 lp_git=""
 if _lp_vcs_head_status; then
 lp_git+="$lp_vcs_head_status"
 fi
 if _lp_vcs_unstaged_lines; then
 lp_git+="$LP_COLOR_CHANGES <span class="naked_sign">○</span><span class="naked_aural">しろまる</span>+$lp_vcs_unstaged_i_lines/-$lp_vcs_unstaged_d_lines"
 fi
 if _lp_vcs_commits_off_remote; then
 lp_git+="$LP_COLOR_COMMITS <span class="naked_sign">○</span><span class="naked_aural">しろまる</span>+$lp_vcs_commit_ahead$NO_COL/$LP_COLOR_COMMITS_BEHIND-$lp_vcs_commit_behind$NO_COL"
 fi
```
Notez que la logique d’affichage (ou non) est découplée du schéma de coloration. Cela ne vous semble peut-être pas plus simple, mais au moins vous pouvez le lire sans avoir mal à la tête, et il me semble que vous pouvez l’adapter plus facilement à un plus grand nombre de cas d’utilisation, et qu’il a une granularité plus fine sur l’information qu’il peut afficher.
Maintenant, tout comme il est très difficile de concevoir de bons systèmes de *build* (qui sont un mélange de programmes déclaratifs et impératifs), c’est un problème notoirement difficile que de concevoir un système de configuration (pour les mêmes raisons). Ne soyez donc pas trop durs avec les développeurs, il n’y a pas de solution miracle.
### Déclaration contre Innovation
Le deuxième problème se manifeste dans la diversité des thèmes que les gens peuvent produire dans la pratique. La [liste des thèmes disponibles pour Oh-My-Posh](https://ohmyposh.dev/docs/themes) est impressionnante. Il ne fait aucun doute que l’approche déclarative incite les gens à créer des thèmes. Toutefois, lorsque l’on parcourt la longue liste, il est évident qu’ils se ressemblent tous. Il ne faut pas s’attendre à des designs très différents avec ce prompt, ce ne sont que des listes de segments colorés.
Ici, Liquid Prompt présente une différence intéressante. Vous pouvez reconfigurer les thèmes avec l’approche classique `clé=valeur`, mais plus généralement, les thèmes sont de purs scripts shell qui *arrangent* les informations disponibles. Cela permet toutes sortes de subtilités, et plus généralement d’afficher n’importe quelle information sous n’importe quelle forme, pour n’importe quelle combinaison d’états, ce qui est totalement impossible à faire de manière efficace avec une approche déclarative.
Par ailleurs, l’approche utilisée par Liquid Prompt permet de combiner facilement des configurations (appelées *presets*). Ainsi, vous pouvez utiliser un thème, puis utiliser un *preset* pour modifier certaines de ses couleurs (par exemple si vous êtes daltonien).
L’impact de cette approche est visible dans la [diversité des thèmes proposés par Liquid Prompt](https://github.com/liquidprompt/liquidprompt/wiki/Themes). Il ne s’agit pas seulement de changer les couleurs et les icônes, mais de modifier l’ensemble de l’expérience utilisateur. Par exemple, le thème [GitCrux](https://github.com/nojhan/lp-gitcrux) reprend le thème par défaut, mais ajoute des indications visuelles sur les commandes Git qui peuvent être utiles compte tenu de l’état du référentiel actuel. Pour ce thème, Liquid Prompt est plutôt un fournisseur de données, un* moteur de thème* qu’il utilise à ses propres fins.
On peut également voir une certaine innovation dans le [thème DotMatrix](https://github.com/nojhan/lp-dotmatrix), où certaines informations sont affichées non pas avec des icônes/segments, mais simplement avec des espaces orientés. Par exemple, dans Dotmatrix, lorsque vous êtes connecté via SSH, un espace entouré de flèches vers la gauche est inséré entre le type de terminal (c’est-à-dire une session purement textuelle ou graphique) et l’utilisateur. Il en va de même pour indiquer une session multiplexée : un espace est inséré entre l’utilisateur et le nom d’hôte. Le thème utilise la même idée pour le contrôle de version, et pour indiquer que des commits attendent d’être poussés (flèches espacées vers la gauche — là où se trouve le serveur) ou retirés (flèches espacées vers la droite — là où *vous* vous trouvez).
Ce type de conception nécessiterait une refonte complète du moteur de thème dans d’autres systèmes de prompt, mais ne requiert qu’un développeur motivé connaissant un peu de shell avec Liquid Prompt.
# Fonctionnalités
Le design, c’est bien, mais en fin de compte, les logiciels doivent avoir les fonctionnalités qui comptent. Vous savez, genre avoir quelque chose à afficher.
Pour entrer dans les détails des fonctionnalités, j’ai dressé la liste de toutes les fonctionnalités de chaque système d’invite, puis j’ai vérifié lesquels les prenaient également en charge. J’ai ensuite évalué la qualité de cette prise en charge :
0. aucune prise en charge,
1. prise en charge et conception de base,
2. bon ensemble de fonctionnalités, mais ergonomie médiocre,
3. bonnes fonctionnalités et ergonomie.
Les résultats sont présentés dans le tableau suivant, et les réflexions sur ce que cela signifie dans les sections suivantes.
Dans ce tableau, les nombres dans les cellules indiquent le niveau de qualité de la fonctionnalité. La popularité est la somme des niveaux de la ligne. Les lignes « support » correspondent à la somme des niveaux de la colonne, pour chaque catégorie. Les catégories sont triées de haut en bas en fonction de leur popularité moyenne. Les projets sont triés de gauche à droite, en fonction de leur score de support dans la section des essentiels du shell.
Les sections suivantes abordent certains des ensembles de fonctionnalités présentés dans ce tableau et les comparaisons entre les systèmes d’invite.
[Tableau de support des principaux systèmes de prompts](https://camo.githubusercontent.com/a39022857261f072e32a7954f28c7c12e3be340ff38742d747034aba682e405a/68747470733a2f2f6c697175696470726f6d70742e72656164746865646f63732e696f2f656e2f6c61746573742f5f696d616765732f70726f6d7074735f636f6d70617269736f6e2e737667)
## Les fonctionnalités essentielles sont essentielles
Le shell est un logiciel assez ancien. Vieux dans le bon sens du terme : il a été testé et mis à jour pour atteindre un niveau de qualité qui permet de travailler efficacement. De plus, il est fort probable que vous y passiez la plupart de votre temps à travailler sur quelques types de tâches : développeur, sysadmin, devops, analyste de données, ou n’importe quelle variante de ces familles. Quel que soit votre travail, il vous serait probablement utile de connaitre (et d’utiliser) un ensemble de fonctionnalités pour utilisateurs « chevronnés ». Si vous avez lu cet article jusqu’ici, il y a de fortes chances que vous soyez à l’aise avec le shell et que vous soyez un utilisateur expérimenté, ou que vous aspiriez à l’être.
La tâche principale du shell est d’afficher une sorte d’état lié à la machine, au shell/à l’environnement ou au répertoire courant. Les états les plus importants sont soit ceux fournis par le shell lui-même, soit ceux qui peuvent gêner votre travail (probablement l’état de l’ordinateur lui-même). Ces fonctionnalités sont essentielles, et elles devraient avoir une place de premier ordre dans l’invite.
Dans le tableau ci-dessus, j’ai séparé les fonctionnalités liées à la machine et au shell en deux catégories : les fonctionnalités essentielles et les fonctionnalités diverses. La catégorie « divers » contient les fonctionnalités liées au réseau, car elles sont notoirement criblées de toutes sortes d’écueils. J’ai également placé la fonction « dir stack » (les commandes `pushd` et `popd`) dans cette catégorie, car elle n’est pas fréquemment utilisée par les utilisateurs. C’est dommage, car il s’agit d’une fonctionnalité puissante. J’y ai également placé [direnv](https://direnv.net/). Bien qu’il ne s’agisse pas d’une fonctionnalité principale de l’interpréteur de commandes (il s’agit après tout d’un logiciel externe), elle est très proche d’une fonctionnalité principale de l’interpréteur de commandes et j’ai pensé qu’elle méritait plus que la catégorie « contexte de développement ».
Dans notre tableau, les prompts sont classés en fonction de leur capacité à prendre en charge ces fonctionnalités essentielles. Il devrait être évident en voyant le tableau que Liquid Prompt a de loin le meilleur support. Les autres prompts sont bien moins équipés, Starship a un bon support, bien qu’avec des choix ergonomiques discutables (comme nous l’avons vu dans la section *Design*), suivi par Oh-My-Posh et Powerlevel10k, tous deux avec un support moyen et une ergonomie générale moyenne. Pure a un support médiocre de par sa conception même, ce qui ne peut lui être reproché, mais si vous êtes un utilisateur expérimenté plutôt qu’un ascète, vous pourriez avoir une opinion peu amène quant à ce choix.
## Prendre soin de l’environnement
Pour les tâches du développeur, il est essentiel de connaitre le contexte logiciel dans lequel vous travaillez. Bien entendu, il faut diviser ce contexte en fonction de la prise en charge de tel ou tel logiciel. Il existe deux catégories générales à cet égard : les logiciels qui manipulent la configuration actuelle de votre session (*environnements virtuels* proprement dits) et la version actuelle de tout outil lié à la tâche en cours (*toolset*). Si vous jouez avec des conteneurs toute la journée, vous allez adorer ces fonctionnalités (une fois que vous aurez trouvé un moyen d’y installer un prompt).
En ce qui concerne la catégorie « environnements », le support est assez faible parmi les principaux concurrents (Liquid Prompt, *ship, et PowerLevel10k), Starship ayant le meilleur support global et la meilleure ergonomie. Oh-My-Posh est un peu en retrait, et Powerline presque nulle part. Pure, comme d’habitude, a décidé de ne pas supporter ce genre de choses.
Mais le vrai clivage est dans la catégorie *toolset*, avec Pure et Powerline qui ont décidé de ne pas supporter ce genre de fonctionnalités, Liquid Prompt qui ne supporte que deux outils, et *ship, Oh-My-Posh et PowerLevel10k qui misent à fond dessus. Parmi eux, Starship est le vainqueur incontesté, avec une liste impressionnante d’outils pris en charge.
Cependant, cette catégorie a tendance à avoir une expérience utilisateur très limitée, chaque fonctionnalité étant réduite à « afficher simplement l’icône & la version ». Pour la plupart d’entre elles (comme les langages de programmation), cela peut être facilement compris, puisqu’il n’y a pas grand-chose à signaler de toute façon. Pour d’autres (comme les systèmes de *build*), je pense que les prompts peuvent mieux faire.
Dans l’ensemble, je ne suis pas complètement convaincu que cette catégorie de fonctionnalités soit suffisamment importante pour remplir le prompt avec des icônes et des chiffres, mais puisque Starship semble le juger crucial, il y a surement des cas d’usage pour cela.
En passant, on peut voir que Starship se dit « minimal » sur sa page d’accueil, ce qui ne correspond pas tout à fait au niveau de support qu’il a pour ces *toolsets*... mais je m’éloigne du sujet.
## Il est temps
La rapidité du prompt — c’est-à-dire le temps nécessaire pour l’afficher après l’exécution d’une commande — est une caractéristique qui fait l’objet de discussions constantes de la part des utilisateurs. 
Vous pourriez penser qu’il s’agit d’une fonctionnalité très importante et qu’aucun compromis ne doit être fait à ce sujet. Mon point de vue est légèrement différent.
L’interpréteur de commandes est une interface de commande. C’est-à-dire que vous tapez, entrez, regardez le résultat de la commande, puis réfléchissez à la suivante. Il y a de fortes chances que vous ne tapiez jamais frénétiquement *Entrée* après une commande qui a été très rapide à produire son résultat. Vous tapez, vous réfléchissez, vous tapez la commande suivante. Vous n’avez pas besoin de la latence d’un jeu de tir à la première personne.
Bien sûr, il existe un seuil au-delà duquel la latence de l’affichage commence à produire des frictions. L’auteur de PowerLevel10k a [discuté en détail de ce qui est impossible à distinguer d’une absence de latence](https://github.com/romkatv/zsh-bench#how-fast-is-fast), ce qui vous donne une idée de la *plus petite* latence que vous pouvez remarquer, mais pas tout à fait celle que vous tolèreriez dans une session typique.
De ce point de vue, il y a un vainqueur incontestable : PowerLevel10k est incroyablement rapide. Il est allé très loin pour réduire sa latence, et a réussi quelques tours de force techniques très impressionnants, comme l’affichage asynchrone d’éléments lents, grâce à une « évaluation paresseuse ». Cela explique aussi en grande partie pourquoi il ne supporte que Zsh.
Je comprends l’intérêt de réduire les frictions liées à l’attente de la frappe ; mais je pense que l’on surestime souvent l’intérêt d’une latence ultra-faible, quand le prix à payer est que l’information intéressante peut ne pas être affichée au moment où l’on a besoin d’y penser.
Un fait intéressant concernant la latence est la curieuse affirmation de Starship à ce sujet. Sur sa page d’accueil, il affirme que Starship est « incroyablement rapide », *parce qu’il est programmé en Rust*, qui « apporte la meilleure vitesse, toutes catégories ». Cette affirmation ne tient pas vraiment la route face à la vraie vie. Non seulement Starship est beaucoup plus lent que PowerLevel10k, mais il est également plus lent que Liquid Prompt — tous deux écrits en pur script shell — dans la plupart des cas d’utilisation simple ! Oh-My-Posh — écrit en Go — ne se risque pas à faire le même genre d’affirmation, par exemple.
[Romkatv explique pourquoi dans son étude](https://github.com/romkatv/zsh-bench#prompt) :> « Starship est implémenté en tant que binaire externe, il doit donc payer le prix d’au moins un fork+exec supplémentaire pour chaque commande par rapport aux prompts natifs de zsh. Un seul fork+exec ne peut pas expliquer le décalage élevé dont Starship fait preuve, alors qu’est-ce qui se passe ? Dans les conditions de référence, Starship clone 158 fois ! C’est coûteux. »
C’est peut-être contre-intuitif pour la plupart des informaticiens peu expérimentés, mais le langage est loin d’être l’aspect le plus important de la programmation.
# Conclusion
Si vous entrez suffisamment dans les détails, vous pourrez probablement toujours argumenter que tel ou tel système de prompt est le meilleur pour tel ou tel utilisation très spécifique. Grâce aux informations fournies dans cet article, j’espère que vous pourrez décider par vous-même. Maintenant, si vous préférez une évaluation globale, je pense qu’il est clair qu’il y a quelques systèmes qui conviennent mieux à certaines utilisations majeures.
## Certains sont *out*
Tout d’abord, je pense que l’on peut affirmer sans risque de se tromper qu’il y a très peu d’intérêt à choisir Pure, si ce n’est pour signaler que vous vous positionnez comme étant aligné avec ses valeurs (c’est-à-dire que vous croyez au « one size does fit all », ou « je n’utilise pas vraiment le shell de toute façon »). La plupart des autres candidats ont des thèmes qui reproduisent son (absence) de fonctionnalité, et proposent même d’avoir le même style, mais en supportant plus de cas d’utilisation (d’autres systèmes de version, plus d’alertes sur l’état de l’ordinateur, etc.).
De même, Powerline n’est probablement pas très utile en dehors de son marché principal, qui est de produire des lignes d’état. Et même les autres prompts peuvent généralement fournir beaucoup plus d’informations pour ce faire, à l’exception de certains services en ligne spécifiques.
En outre, Spaceship peut également être mis de côté en toute sécurité, étant donné qu’il a été en pratique remplacé par Starship, qui prend en charge davantage de fonctionnalités (à moins que vous n’ayez besoin d’une identification très spécifique de l’ensemble d’outils, voir le tableau ci-dessus).
Après avoir longuement hésité, j’ai décidé de mettre également de côté Oh-My-Posh. Cela n’a pas été facile, étant donné qu’il est assez bon sur presque tous les critères d’évaluation que j’ai développés dans cet article, ce qui est déjà une belle réussite. Mais c’est là que réside son défaut : il n’est que moyen partout.
## Certains sont *in*
Il nous reste donc Liquid Prompt, Starship et PowerLevel10k.
PowerLevel10k est le plus populaire (selon la métrique des étoiles de Github) et est le choix évident si vous vous souciez plus de la latence que des fonctionnalités. Il a un support plutôt moyen de chaque catégorie de fonctionnalités, mais a travaillé très dur pour fournir une latence ultra-faible entre deux commandes. Je ne suis pas sûr que cela vaille la peine de réduire les fonctionnalités et la portabilité, étant donné que je suis très rarement ennuyé par de grandes latences lorsqu’elles se produisent dans d’autres systèmes de prompts, mais votre appréciation peut différer (chacun ses fixettes). Il a néanmoins quelques choix de design très modernes et innovants, que j’aime beaucoup, même si j’ai l’impression qu’ils sont plus des paillettes techniques impressionnantes qu’un design vraiment utile ancré dans l’expérience de l’utilisateur.
Starship n’est pas loin derrière en termes d’étoiles, et brille évidemment par son soutien à l’identification des versions d’outils. L’utilité de ce système pour vous dépend de la fréquence à laquelle vous jonglez avec des tâches de développement complexes. En tant qu’ingénieur de recherche, je jongle constamment avec un ensemble de tâches très diverses, et je suis donc plus attiré par des systèmes qui couvrent bien les fonctionnalités de base du shell que par l’énumération des versions, mais je suppose que cela peut être débattu. Quoi qu’il en soit, si vous avez besoin de la portabilité vers PowerShell, Starship est un choix sûr. Gardez également à l’esprit que ses revendications en matière de latence sont exagérées.
Bien qu’il soit le plus ancien de tous, Liquid Prompt est aussi le moins connu. Cependant, il offre le meilleur support des fonctionnalités essentielles. Je dirais aussi qu’il a prêté plus d’attention à son design, permettant des prompts très denses, par exemple. Il est également très configurable, ce qui a permis de créer des thèmes très originaux en termes d’expérience utilisateur. C’est probablement le prompt qui servira le plus grand nombre de cas d’utilisation et d’utilisateurs, en particulier les personnes souhaitant apprendre le shell en expérimentant toutes ses fonctionnalités.
# Vers le service et au-delà
Cet article vous a donné quelques opinions basées sur une analyse à un moment donné d’un marché qui continue d’évoluer. En tant que tel, il ne constitue qu’un point dans le temps et peut très bien être rendu obsolète par un changement soudain dans l’activité de l’un ou l’autre projet.
Au cours de l’histoire des systèmes de prompts, tous ont découplé la collecte des données et leur affichage. Et la collecte des données est l’opération la plus couteuse, qui retient toute l’attention lorsque le temps d’exécution doit être optimisé. PowerLevel10k, par exemple, a complètement découplé les deux opérations, qui s’exécutent désormais dans des coroutines parallèles. Son auteur a même mis en place un [service de status pour Git](https://github.com/romkatv/gitstatus) totalement précurseur, qui permet d’accélérer considérablement les prompts.
Une autre tendance intéressante consiste à découpler la collecte des données en éléments logiciels atomiques, comme les plugins. Starship n’aurait probablement pas eu son impressionnant support d’outils s’il n’y avait pas eu sa base de code propre et modulaire.
En même temps, Liquid Prompt a fait de gros efforts pour permettre aux thèmes de décider de ce qu’il faut afficher et (plus important) comment et quand l’afficher, allant plus loin que de considérer les thèmes comme de simples configurations.
Je pense que ces trois tendances convergent vers l’idée d’un *service* d’invite, où le *serveur* est responsable de la collecte et de la mise en cache des données, tandis que le *client* est responsable de l’articulation de ces informations d’une manière qui soit utile à l’utilisateur (et pas seulement en les affichant).
L’idée a été explorée ici et là, à ma connaissance surtout par les développeurs de Liquid Prompt, avec des projets tels que [AngelPS1](https://github.com/dolmen/angel-PS1) de Dolmen et [MOST](https://github.com/Rycieos/most) de Rycieos. Si vous aimez ça, le mainteneur de Liquid Prompt a lancé [une conversation sur les « moteurs de thèmes »](https://github.com/liquidprompt/liquidprompt/discussions/786), n’hésitez pas à la rejoindre et à participer à l’élaboration de l’avenir des systèmes de prompts !
</div><div class="naked_ctrl">
<form action="/index.cgi/contrast" method="get" name="gate">
<p><a href="http://altstyle.alfasado.net">AltStyle</a> によって変換されたページ <a href="httpS://linuxfr.org/news/comparaison-critique-de-systemes-d-invite-de-commande.md">(-&gt;オリジナル)</a>
/ <label>アドレス: <input type="text" name="naked_post_url" value="httpS://linuxfr.org/news/comparaison-critique-de-systemes-d-invite-de-commande.md" size="22" /></label> <label>モード: <select name="naked_post_mode">
<option value="default">デフォルト</option>
<option value="speech">音声ブラウザ</option>
<option value="ruby">ルビ付き</option>
<option value="contrast" selected="selected">配色反転</option>
<option value="larger-text">文字拡大</option>
<option value="mobile">モバイル</option>
</select>
<input type="submit" value="表示" />
</p>
</form>
</div>