Starship : un prompt petit, rapide et personnalisable pour tous les shells

 (starship.rs)
8 points par GN⁺ 2025-06-25 | 2 commentaires | Partager sur WhatsApp
  • Starship est un projet open source de prompt léger, performant et flexible, utilisable dans divers environnements shell
  • Large compatibilité avec la plupart des principaux shells, dont Bash, Zsh, Fish, Powershell et Tcsh
  • Configuration et activation possibles en ajoutant simplement le script d’initialisation propre à chaque shell
  • Écrit en Rust, il garantit rapidité et sécurité, et est distribué sous la forme d’un binaire unique
  • Chaque détail, même mineur, peut être personnalisé
  • Prend en charge une configuration d’environnement commune sur de nombreuses plateformes, dont Android, BSD, Linux, macOS et Windows, pour améliorer la productivité et la facilité d’utilisation

Projet open source Starship

  • Starship est un outil de prompt qui combine performances et personnalisation, et peut être utilisé sur différents systèmes d’exploitation et shells
  • Par rapport aux prompts traditionnels plus lourds, il se distingue par une réactivité élevée et une faible consommation de ressources, tout en offrant un haut niveau de personnalisation qui contribue à améliorer la productivité des développeurs

Méthode de configuration selon l’environnement shell

  • Bash:
    • Ajouter le code eval "$(starship init bash)" à la fin du fichier ~/.bashrc
  • Fish:
    • Ajouter starship init fish | source à la fin du fichier ~/.config/fish/config.fish
  • Zsh:
    • Ajouter le code eval "$(starship init zsh)" à la fin du fichier ~/.zshrc
  • Powershell:
    • Ajouter Invoke-Expression (&starship init powershell) dans le fichier Microsoft.PowerShell_profile.ps1
    • L’emplacement du fichier de profil PowerShell peut être vérifié avec la variable $PROFILE
  • Ion:
    • Saisir le code eval $(starship init ion) dans le fichier ~/.config/ion/initrc
  • Elvish:
    • Seule la version v0.18 ou ultérieure est prise en charge
    • Ajouter le code eval (starship init elvish) dans le fichier ~/.elvish/rc.elv
  • Tcsh:
    • Saisir le code eval \starship init tcsh`` dans le fichier ~/.tcshrc
  • Nushell:
    • Seule la version v0.96 ou ultérieure est prise en charge ; la méthode de configuration pourra évoluer à l’avenir
    • Le chemin du fichier de configuration peut être vérifié avec la commande $nu.config-path
    • Appliquer dans ce chemin le code starship init nu | save -f ...
  • Xonsh:
    • Saisir le code execx($(starship init xonsh)) à la fin du fichier ~/.xonshrc
  • Cmd (Clink requis):
    • Clink v1.2.30 ou ultérieure est requis
    • Créer un fichier starship.lua, puis l’enregistrer dans le répertoire des scripts Clink
    • Ajouter à l’intérieur le code load(io.popen('starship init cmd'):read("*a"))()

À lire aussi

2 commentaires

 
tujuc 2025-06-25

Ça fait drôle de voir passer ici quelque chose que j’utilise très bien depuis des années :)
Je l’utilise depuis l’époque où c’était proposé comme thème Zsh... hahaha
 
GN⁺ 2025-06-25
Commentaires Hacker News

  • Je suis un utilisateur qui aime les prompts maximalistes, et j’utilise souvent Shell Bling Ubuntu via Starship quand je monte une machine de dev
    Cela dit, ce style ne convient pas à tout le monde
    Si vous ne voulez ajouter que l’information la plus dense, je recommande d’afficher seulement l’heure à laquelle le prompt apparaît et la durée d’exécution de la dernière commande
    Avec seulement ces deux informations, il est facile de comprendre ce qui s’est passé et quand, ce qui est très utile plus tard pour le débogage ou la tenue d’un historique
    C’est une astuce tirée de Networking for System Administrators de Michael W. Lucas, un livre que je recommande souvent aussi aux développeurs qui veulent apprendre les bases du réseau
    Si vous voulez gagner encore plus de points de nerd, affichez l’heure en secondes selon l’époque UNIX
    Cela rend le calcul des deltas de temps extrêmement simple
    Voir le repo Shell Bling Ubuntu

    • Dans nushell, ce genre d’informations est fourni par défaut
      Dans l’historique d’exécution, on peut consulter des détails comme l’horodatage de début de la commande, son temps d’exécution, le répertoire courant, l’état de sortie, etc.
      C’est très pratique, car cela montre directement non seulement l’écart de temps entre les commandes, mais aussi la durée d’exécution de la commande elle-même

    • Je n’ai presque jamais personnalisé mon prompt
      Avec emacs, je peux déjà voir dans l’éditeur toutes les informations dont j’ai besoin
      Je ne configure Starship que quand je dois montrer quelque chose à quelqu’un, par exemple en pair programming, et j’ouvre alors une application de terminal séparée pour ne pas avoir à exposer ma configuration

    • Le code de sortie de la commande précédente est aussi une information très utile, pour des raisons similaires à celles citées plus haut

    • Afficher l’heure actuelle dans un format lisible par un humain aide aussi pas mal
      Et afficher l’état de sortie de la commande précédente lorsqu’il n’est pas égal à 0 (en cas d’échec) aide au débogage

    • Pour moi, l’information sur le répertoire courant suffit à elle seule
      Il me suffit de changer la couleur du prompt selon que la dernière commande a réussi ou échoué
      Pour le reste, je vérifie séparément quand j’en ai besoin

  • Cela m’a rendu curieux de connaître la répartition par âge des utilisateurs de Starship
    Pour ma part, avec le temps, j’ai largement perdu tout intérêt pour la personnalisation du prompt
    J’en suis arrivé à la conclusion que, même avec un prompt très sophistiqué, 90 % des informations affichées sont inutiles 90 % du temps
    Trop d’informations finissent au contraire par devenir du bruit visuel, au point que le cerveau les ignore et qu’on en oublie même leur présence
    Les informations vraiment importantes atteignent vite les limites du prompt ; par exemple, savoir qu’il y a des changements sur une branche Git ne dit pas quels fichiers ont changé, donc il faut de toute façon lancer des commandes supplémentaires

    • Plus de 20 ans de carrière dans le développement
      Je trouve très utile d’avoir les informations Git dans le prompt
      Cela ne donne pas tous les détails, bien sûr, mais c’est pratique pour me rappeler qu’il y a des modifications non commit ou un stash oublié
      Starship m’a intrigué, donc je l’ai installé tout de suite, mais les éléments comme l’affichage des versions d’outils m’ont semblé trop bruyants, et je l’ai finalement désinstallé
      Les options comme le timing des commandes ou leur état de succès/échec étaient intéressantes, mais pas au point de justifier l’effort d’entretien d’une configuration complexe

    • En tant que senior avec plus de 25 ans dans le secteur, je n’utilise généralement pas les outils modernes trop tape-à-l’œil
      Avant, j’utilisais un PS1 très simple qui affichait seulement l’heure, mon compte, l’hôte de connexion et le chemin courant, comme ceci : <pre><code>export PS1="[\033[1;32m][\t \u@\h \w]\$[\033[0m]"</code></pre>
      J’ai essayé plusieurs prompts plus avancés, mais ils m’ont rarement aidé
      En ce moment, j’utilise Starship avec satisfaction depuis plusieurs années
      Je l’ai personnalisé pour n’afficher que le strict nécessaire, et c’est très rapide et agréable à utiliser

    • L’un des éléments les plus utiles de ma personnalisation du prompt est l’affichage de l’exit status de la commande précédente
      Il arrive qu’une commande échoue sans aucun message d’erreur, donc avoir un indicateur d’échec est un signal très fort
      En revanche, pour éviter le bruit au quotidien, je ne l’affiche qu’en cas d’échec
      Par exemple : <pre><code>» true » false (last command returned 1.)</code></pre>
      S’il s’agit d’une terminaison par signal, je l’affiche aussi sous une forme traduite, du genre « last command exited on SIGSEGV »
      C’est également utile dans le cas inverse, lorsqu’un programme affiche un message d’erreur mais se termine malgré tout avec un code de succès

    • En tant qu’utilisateur « very senior » avec des dizaines d’années d’expérience sur UNIX, je préfère le mode minimal de Starship, que je trouve propre
      Autrefois, j’ai passé des années à me battre avec différentes configurations zsh, mais aujourd’hui je n’ai presque plus de hassle
      Si vous vous imaginiez que les utilisateurs de Starship étaient tous de jeunes gens qui abusent des emoji en JavaScript, sachez qu’il y a aussi des gens comme moi

    • Plus largement, c’est un phénomène qui s’applique à tout l’environnement informatique
      Quand j’étais plus jeune, j’étais absorbé par le fait de construire moi-même mon OS avec Gentoo, d’ajuster les flags d’optimisation CPU, le gestionnaire de fenêtres, les alias et fonctions dans le bashrc, jusqu’au prompt
      Ce travail d’optimisation en soi a été une expérience très formatrice
      Si l’on fait une analogie avec le travail du bois, au début on passe l’essentiel de son temps à fabriquer et peaufiner des outils ou des petits trucs, puis à un certain moment on se recentre sur le vrai travail pratique
      J’aime toujours Linux aujourd’hui, mais dans une vie bien remplie je privilégie le « travail » plutôt que l’efficacité ou la finition idéales, donc j’utilise simplement Debian et KDE comme environnement par défaut

  • Je n’aime ni les décorations inutiles ni l’excès d’informations, donc je préfère un environnement terminal minimaliste
    Mais Starship montre très bien le contexte quand il le faut et permet une personnalisation fine
    Mon prompt par défaut n’affiche que le répertoire courant, l’heure et un simple %
    Si certaines variables d’environnement sont définies (KUBECONFIG, OS_CLOUD, etc.), il inclut alors les informations correspondantes
    Il affiche aussi automatiquement les versions de langages comme Go ou Python selon le contexte d’utilisation
    Starship rend vraiment ce type de configuration très facile, sans empilement complexe de plugins zsh et avec un overhead minimal
    En particulier, utilisé avec evalcache, l’initialisation est aussi très rapide

  • En tant que fan de Starship, quelques commentaires
    Le fait qu’il soit développé en Rust, donc sûr et rapide, et distribué sous forme de binaire compilé lui donne des performances bien supérieures à powerline basé sur Python, ohmybash basé sur des scripts shell, ohmyzsh basé sur zshell, ou spaceship
    Il prend naturellement en charge zsh, bash, sh et fish, mais aussi MS Windows CMD et Powershell
    Le fait de pouvoir gérer les prompts de tous ses systèmes avec un unique fichier de configuration est presque unique
    Si les informations sont trop nombreuses, on peut très facilement simplifier, et il est aussi possible de désactiver les icônes
    Avec environ 100 modules, les possibilités de personnalisation sont pratiquement illimitées

  • Je ne comprends pas pourquoi Starship est présenté comme « minimal » dans son marketing
    En réalité, il a énormément de fonctionnalités, et dans l’usage réel on voit souvent d’énormes prompts couverts de décorations
    Moi, j’utilise quelque chose d’aussi simple que ça

    <pre><code>: ▶</code></pre>

    Si l’on veut du vrai minimalisme, on n’a pas forcément besoin d’un framework de personnalisation comme celui-ci

    • Par rapport aux autres shells et prompts, le fichier de configuration de Starship a l’avantage de rester assez intuitif même quand la complexité augmente

    • On peut tout désactiver
      En ce moment, j’utilise une configuration minimale qui ressemble à ceci

      <pre><code>format = """ $username\ $hostname\ $shlvl\ $directory\ $git_branch\ $git_commit\ $git_state\ $git_metrics\ $git_status\ $package\ $python\ $rust\ $env_var\ $custom\ $cmd_duration\ $jobs\ $time\ $status\ $shell\ $character"""</code></pre>

    • Au fond, Starship peut certes être utilisé de manière minimaliste, mais par nature c’est surtout un prompt maximaliste capable d’embarquer autant d’informations et de contenu que possible
      Ce serait bien de le reconnaître

    • J’utilise une flèche encore plus fine que ça

      <pre><code>PROMPT='%{%F{red}%}%~ %{%F{yellow}%}% › %{%F{reset_color}%}%'</code></pre>

      C’est propre, simple et minimal

  • Je suis surpris par les réactions qui confondent la capacité de personnalisation avec le maximalisme
    Les valeurs par défaut sont un peu chargées, mais on peut les réduire autant qu’on veut
    Je travaille sur plusieurs environnements AWS et avec divers runtimes, et les informations de contexte dans le prompt m’aident réellement beaucoup
    Personnellement, j’utilise depuis longtemps la combinaison Starship + Nushell

  • J’aime le fait qu’une fois installé, il n’y ait plus besoin d’y toucher
    J’aime voir immédiatement si mon shell tourne sur node 20 ou 22, ou si rust est en stable ou en nightly
    Comme tout cela s’affiche directement sans travail supplémentaire, ça me convient très bien

  • Indépendamment de Starship, il y a un phénomène gênant dans les prompts zsh : quand on appuie sur Entrée, le curseur se déplace brièvement vers le début de la ligne, provoquant une sorte de « flash »
    C’est moins visible avec un prompt ultra-rapide, mais dès qu’il se passe la moindre chose dans le prompt, ce phénomène saute aux yeux
    Je l’ai observé de la même manière dans plusieurs terminaux (gnome-terminal, wezterm, kitty, alacritty, xterm)
    Le seul terminal où ce problème n’apparaît pas est urxvt
    Voir la vidéo de reproduction
    Je suis curieux de connaître la cause de ce flash et les moyens de l’éviter

  • Si, toutes les 100 ms, le prompt va vérifier des informations peu utiles comme git status à chaque rendu, cela finit par provoquer une baisse de productivité invisible
    Le terminal devrait être un outil mémoriel réactif, et il faut éviter qu’il devienne une décoration superflue
    Le problème, c’est qu’on fait très attention à la vitesse d’exécution du code tout en restant étrangement tolérant vis-à-vis de la latence de frappe

    • Starship est vraiment rapide
      La collecte des données nécessaires ne prend que quelques ms, et on peut facilement contrôler quelles informations extraire
      Avec les autres outils que j’ai utilisés jusque-là, les délais me gênaient toujours, mais avec Starship la différence est très sensible

    • Les 100 ms perçues par un humain et les 100 ms de l’optimisation CPU sont deux choses complètement différentes
      À mon avis, cela pousse à se demander ce qu’il faut le plus optimiser entre un prompt qui met 100 ms à afficher une branche ou un état git, au risque de casser le flow, et le temps plus long que je mets moi-même à saisir une commande
      Quelques ms consacrées à des fonctions de confort raisonnables valent largement le coût
      Au final, tout revient à trouver un point d’équilibre entre confort et minimalisme
      Un minimalisme extrême comme une décoration excessive peuvent tous deux conduire à l’inefficacité

    • Comme cette latence m’agaçait, j’ai patché le terminal kitty pour déplacer le prompt Starship dans une barre d’état en bas, comme la status bar ou modeline de vim ou emacs
      La modeline se met à jour de manière asynchrone, donc la réactivité du prompt est excellente
      L’inconvénient, c’est qu’il faut patcher kitty soi-même, et je n’ai pas pu tester cela en dehors de mon environnement Linux personnel
      Voir le projet de patch associé

    • Je me demande s’il serait possible pour un outil de prompt d’agir un peu comme un TUI, c’est-à-dire de modifier de manière asynchrone la zone du prompt même après avoir complètement rendu sa sortie initiale (par exemple, kubectl, git ou aws cli pourraient ajouter des informations 200 ms plus tard)
      De cette façon, l’utilisateur pourrait taper sa commande suivante immédiatement sans attente, et les informations supplémentaires apparaîtraient ensuite naturellement

    • Je me demande si, au lieu d’optimiser l’exécution du code, le vrai problème n’est pas plutôt que l’empilement des couches rend en pratique plus difficile l’optimisation de la latence d’entrée du prompt

  • En allant sur le site officiel, j’ai eu l’impression qu’il manquait une explication claire de pourquoi utiliser Starship
    Ces derniers temps, ma personnalisation du prompt me montre d’un coup d’œil les informations suivantes

    <pre><code>- résultat de la dernière commande (couleur : vert, rouge, violet)
  • user@host:currentDirectory
  • (dans un repo) branche courante et résumé du git status, jobs en arrière-plan</code></pre>
    Si la dernière commande réussit, c’est vert ; si elle échoue, c’est rouge ; si elle a été interrompue, c’est violet
    Je pourrais bien faire partie de leur cible, mais la page d’accueil ne m’a pas clairement communiqué le « pourquoi » de l’outil ni ce qu’il améliore réellement