Journal Actualité de powerline.bash : optimisations, icônes, nouveaux segments et plus

Posté par Étienne BERSAC (site Web personnel) le 24/03/20 à 11:07. Licence CC By‑SA.

Étiquettes :

mar.

2020

Salut à tous,

En ces temps de chômage technique, je suis sûr que beaucoup d'entre vous profite de ce temps pour mouler^Waffuter leur outil favori : BASH !

Voilà pile 2 ans, j'ai commencé le développement de powerline.bash. Il s'agit d'un fork de l'invite de commande de Sandile Keswa, qui lui n'a pas bougé depuis 2017. Mon but premier était d'adopter le style powerline, d'ajouter le virtualenv Python et autres améliorations. La première mouture a eut un succès relatif (traduire : étonnamment, je ne suis pas le seul à l'utiliser).

L'importance de l'invite de commande

Reconnaissons que ce n'est pas simple de configurer aux petits oignons une invite de commande. Et pourtant, cela me semble crucial tant pour un développeur que pour un administrateur système. Voici les informations qui me semblent essentielles à connaître au moment de rédiger une commande :

qui suis-je ? root ou pas ?
où suis-je ? quelle machine ? quel dossier ?
dans quel état j'ère ? la commande précédente a-t-elle planté ? Suis-je en cours de rebase ? sur quelle branche git ? Ai-je oublié un fichier ?

Ceci permet d'éviter des erreurs du genre :

commande malheureuse en prod ou en root.
oubli de sudo entêtant.
rebasage foiré et perte de commit (avec séjour interminable dans reflog)
push -f sur master et autres occasions d'offrir les chouquettes le lendemain matin.

Pour soi et pour les autres

On peut aller plus loin dans la remonté de l'état du terminal : version de Python, ruby, fichier openrc (OpenStack), état de services docker-compose, etc. Les possibilités sont aussi grandes que les applets sur son bureau.

L'invite de commande est importante aussi pour les autres. Quand est-ce qu'on partage son invite de commande avec son collègue ? Bien plus souvent qu'on ne le croit ! En copi-collant la sortie d'un terminal dans un ticket, en partageant sont écran pour faire une démonstration, en binômant pour chasser un bug. Autant d'occasion où une invite obscure n'aide pas voire trouble le pair.

C'est dans cette optique que j'apprécie les icônes dans l'invite de commande. Il permet de manière concise de distinguer que admin@integration et root@gargamel sont l'un un accès OpenStack et l'autre un accès SSH.

C'est aussi pour les autres que powerline.bash génère une invite sur deux lignes : la première est une sorte de barre d'état avec des segments indiquant l'état du terminal. La deuxième ligne est un simple $ ou # prêt à recevoir la commande. Votre curseur est toujours à la même place. Cette ligne est très facilement copi-collable et sur les forges GitHub ou GitLab, le rendu HTML de markdown console en tient compte.

Simple, rapide, compatible, expressif, joli, extensible

Il y a le choix dans les projets d'invite de commande. Du sapin de Noël à l'invite sobre, tout est dans le commerce. J'ai fait powerline.bash pour avoir en un projet :

Une installation très simple : copier un fichier et le sourcer. pas de serveur.
Une exécution extrêmement rapide. De l'ordre de 15ms avec exécution de git status. Sans git, on descend à 2ms !
Un rendu élégant avec le style powerline, des coleurs choisies et icons-in-terminal.
Une portabilité : vieux bash, vieux git, pas d'icône ni de chevron Powerline.
Un large choix d'informations à remonter : sudo, ssh, dossier courant, branche et synchronisation amont de dépôt git, version pyenv, virtualenv python, openrc openstack, nouveaux messages dans maildir.

Tout cela au prix d'une implémentation pleine de bashismes et avec quelques optimisations obscures.

Collaboration

Le projet est en français à l'instar de Knacss. Vu l'hégémonie de l'anglais parmi les développeurs français, ça détonne. C'est d'abord parce que je ne prétends pas être utilisé par la silicon valley. Ce projet est pour moi, mes pairs.

Récemment, j'ai reçu plusieures contributions majeures de Frédéric MAYNADIER. Discuter du code en français a été très agréable et très efficace. Je suis ouvert à accueillir de nouveaux segments : cela permet de partager du code et de l'optimiser. N'hésitez-pas !

Et vous ? Qu'utilisez-vous ? Partagez-vous votre invite de commande ?

nimage

invite de commande

# trop long

Posté par ʭ ☯ le 24/03/20 à 14:37. Évalué à 4.

à mon humble avis, si ta ligne est plus longue que celle du bash par défaut pour afficher la même information, ça ne prendra pas. Mais ce n'est visiblement par ton but premier…

⚓ À g'Auch TOUTE! http://afdgauch.online.fr
- [^] # Re: trop long
  
  Posté par Étienne BERSAC (site Web personnel) le 25/03/20 à 08:59. Évalué à 5.
  
  Salut,
  
  Effectivement, mon but n'est pas le compacité de l'invite. Je n'aurai pas utilisé les chevrons Powerline alors. Ceci dit powerline.bash n'affiche pas le segment utilisateur@machine sur mon poste, seulement en sudo, ssh, etc. Cela économise pas mal de place. L'utilisation des icônes consomme pas mal de place : 2 à 3 colonnes par icône. Je pense aussi que cela consomme du CPU pour dessiner tout cela.
  
  J'ai dans l'idée d'offrir un rendu alternatif, compact, sans chevrons ni couleurs de fond. Je ne sais pas dans quelle mesure cela remet en cause profondément le code.
  
  ça ne prendra pas
  
  Ça, je m'en cogne :D Je suis très content de voir la diversité des invites de commande dans les commentaires. Je n'ai pas de patreon !
# Commentaire supprimé

Posté par Anonyme le 24/03/20 à 14:37. Évalué à 3. Dernière modification le 24/03/20 à 14:41.

Ce commentaire a été supprimé par l’équipe de modération.
- [^] # Re: Pouvoirligne.bash
  
  Posté par ToasteR (site Web personnel) le 26/04/20 à 22:24. Évalué à 0.
  
  LignePuissante.CoquillageEncoreBourne
  …
# Fish

Posté par abriotde le 24/03/20 à 15:23. Évalué à 1.
Personnellement je suis d'avis de penser que Bash a de gros défaut. Jusqu'ici je n'avais pas été convaincu par ses potentiels successeurs tel ZSH (je l'ai trouvé complexe). Mais Fish me parait vraiment mieux.
- Pour configurer le prompt tu as une IHM Web.
- Lorsque tu tape une commande il te propose automatiquement les commandes similaire de l'historique en plus d'une auto-complétion intelligente et tu peux utiliser les flèche pour faire ton choix dans les propositions.
- Lorsque la ligne est complète, au lieu de passer a la ligne le bout de commande, il passe à la ligne toute la commande. Et quand une commande se termine sans retour chariot, il en rajoute un en te l'affichant clairement.
Alors oui, sur les serveurs que je ne maîtrise, je n'aurais pas Fish avant longtemps (il y a des serveurs ou les prompt sont encore Ksh… ) alors je met PS1="\u@monserv:\w\$ " dans mon .bashrc.
- [^] # Re: Fish
  
  Posté par barmic 🦦 le 24/03/20 à 16:47. Évalué à 2.
  
  fish a un énorme défaut structurel, qui le rend totalement inutilisable pour moi : il a une syntaxe incompatible avec le bourne shell. Ça signifie que tu perd tout l'intérêt d'un shell : l'ubiquité. Le fait que tes shells soient équivalent à ce que tu fais dans ton terminal que tu soit sur ta machine perso ou sur celle d'un collègue ou sur un serveur.
  
  Pour ça je ne l'utiliserais jamais.
  
  ZSH (je l'ai trouvé complexe)
  
  Tu n'a pas besoin de faire des choses complexes avec zsh. Il te propose de créer une première version de ton ~/.zshrc si tu n'en a pas et tu peux commencer à l'utiliser avec le même usage que bash pour l'énorme majorité des choses. Tu peux ensuite tranquillement choisir d'utiliser fonctionnalités en plus quand tu le souhaite.
  
  C'est nettement plus intéressant que fish qui ne s'utilise pas du tout de la même façon que tout les autres shells.
  
  Si je voulais dire que les shell systèmes sont cassés et qu'il faut revoir le truc, je ne partirais pas sur ce qu'à fait fish, mais plus sur les idées derrière ipython ou powershell (qui entre autre ont un typage).
  
  https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
- [^] # Re: Fish
  
  Posté par JJD le 24/03/20 à 16:54. Évalué à 3.
  
  J'adore l'accroche de la page web de fish (https://fishshell.com/) :
  Finally, a command line shell for the 90s
  
  À part ça, je n'avais jamais considéré zsh comme un successeur de bash. Jusqu'à la lecture de ton commentaire (suivi d'une recherche rapide), je pensais même, à tort, que zsh était plus ancien que bash (je me souviens avoir vu arriver zsh sur les serveurs de la fac lorsque j'étais étudiant en remplacement de ksh et n'ai découvert bash que plus tard, sous Linux). Mais même si bash a bien précédé zsh de 1 ou 2 ans, il ne semble pas il y avoir de liens de filiations entre les deux…
  - [^] # Re: Fish
    
    Posté par ʭ ☯ le 26/03/20 à 09:28. Évalué à 2.
    
    Mouais, on sent qu'ils y étaient pas dans les années 90 : en 1994, j'avais un 486 et une carte graphique avec 512ko. Alors les couleurs 24 bits pour un terminal… comment le dire gentiment…
    
    Tous ces shells qui font le café sont hypergourmands, je vous inviter à regarder combien de RAM et CPU ils utilisent!
    
    ⚓ À g'Auch TOUTE! http://afdgauch.online.fr
    - [^] # Re: Fish
      
      Posté par barmic 🦦 le 26/03/20 à 10:22. Évalué à 4.
      
      Tous ces shells qui font le café sont hypergourmands, je vous inviter à regarder combien de RAM et CPU ils utilisent!
      
      Mon htop m'indique 0.0 de CPU et 0.0 de mémoire pour mon zsh :p
      
      Oui ils sont pas aussi léger que ce que tu pouvais trouver dans les années 90, mais ça tombe bien ils ne tournent pas sur du matériel d'époque. Et ce qu'il faut bien comprendre c'est que de mon shell ou de moi ce qui ralentis c'est moi. Donc si mon shell peut m'éviter des actions le gain est largement suffisant pour rendre acceptable les 5~6Mio que mon zsh me coute.
      
      https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# presque monochrome

Posté par CrEv (site Web personnel) le 24/03/20 à 22:51. Évalué à 3.

Et vous ? Qu'utilisez-vous ? Partagez-vous votre invite de commande ?

J'ai en quelque sorte l'inverse d'un powerline (ou tout autre invite du genre) : un shell avec une invite quasiment monochrome.
L'idée est de mettre en valeur la sortie de la commande et non l'invite. Je préfère par exemple avoir des sorties en couleur, qui sont alors bien visibles.

J'ai pour autant le nom de ma branche git (il faudrait que je rajoute mes patch stgit…) et des indicateurs (fichiers modifiés, stash, etc)
Bref tout ce qu'il faut sans être dérangé.

Ce projet est pour moi, mes pairs.

Je suis pas certains de suivre, tes pairs sont forcément francophones ?
- [^] # Re: presque monochrome
  
  Posté par barmic 🦦 le 24/03/20 à 23:24. Évalué à 0.
  
  J'ai bien plus de couleurs que toi :)
  
  Cela me permet de distinguer les sorties de différentes commandes (surtout le rouge le bleu ne sert à rien). J'ai aussi une coloration des commandes, des chemins, des variables et des chaines. Je trouve ça agréable et utile de temps en temps.
  
  Évidement quand je suis dans un dépôt git, j'ai la branche et l'état (quand c'est en cours de rebase par exemple).
  
  https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
  - [^] # Re: presque monochrome
    
    Posté par CrEv (site Web personnel) le 25/03/20 à 10:16. Évalué à 3.
    
    Pour la sortie, j'ai le premier caractère qui change:
    
    Grossièrement je n'ai pas besoin de mon user@machine en local.
    L'heure ou autre est affichée par tmux.
    
    J'ai mis un moment à passer à ce type de shell, j'avais à la base exactement le même mais en couleur. Mais au final celui-ci est très reposant.
    
    Et pour détailler un peu plus, je passe mon temps dans tmux. Genre j'ai une fenêtre (tmux) pour chaque projet. Et généralement je n'ai pas à me déplacer tant que ça dans un même projet. Donc mon emplacement ou autre c'est accessoire la plupart du temps. Ce qui fait que je peux me concentrer sur la commande et la sortie.
    - [^] # Re: presque monochrome
      
      Posté par barmic 🦦 le 25/03/20 à 10:49. Évalué à 1.
      
      Pour la sortie, j'ai le premier caractère qui change:
      
      Quand je scroll, je suis pas sûr que ça me suffise.
      
      Grossièrement je n'ai pas besoin de mon user@machine en local.
      
      J'utilise des dotfiles aussi identiques que possible sur mes serveurs et chez moi (oui je pourrais détecter un shell ssh c'est à essayer).
      
      L'heure ou autre est affichée par tmux.
      
      Là j'ai l'heure de la fin de la précédente commande.
      
      Et pour détailler un peu plus, je passe mon temps dans tmux.
      
      J'utilise pas du tout de multiplexer. Je connais bien le principe, mais avoir les raccourcis de mon WM, puis ceux de l'émulateur de terminal, puis ceux du multiplexer et enfin ceux de mon shell, me donne l'image d'un plate de lasagne assez indigeste… D'autant que tmux comme screen se sont débrouillés pour avoir par défaut des raccourcis que j'utilise.
      
      Ça fait longtemps que j'ai pas retouché ma conf zsh, je vais peut être m'y replonger un peu :)
      
      https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
      - [^] # Re: presque monochrome
        
        Posté par CrEv (site Web personnel) le 25/03/20 à 11:13. Évalué à 3.
        
        puis ceux de l'émulateur de terminal
        
        Déjà ceux-ci je les supprime totalement. J'ai une seule et unique fenêtre de terminal et tout le reste est dans tmux. Donc je n'utilise pas de raccourcis ici.
        
        Pour ce qui est des raccourcis par défaut, ça se change. J'ai un raccourcis tmux principal qui en général fait bondir beaucoup du monde : ctrl-z (parce que je ne m'en sert jamais en temps normal et que ça tombe bien sous les doigts)
        
        Et pour les dotfiles sur serveur, j'ai une autre approche : je ne veux pas avoir des serveurs que j'utilise tellement que je dois avoir des dotfiles dessus :-) Je n'ai maintenant (ok sauf un truc perso) que des serveurs jetables et je ne m'y connecte en général… jamais. Ça résout le problème :-)
        
        [^] # Re: presque monochrome
        
        Posté par barmic 🦦 le 25/03/20 à 11:26. Évalué à 1.
        
        Et pour les dotfiles sur serveur, j'ai une autre approche : je ne veux pas avoir des serveurs que j'utilise tellement que je dois avoir des dotfiles dessus :-) Je n'ai maintenant (ok sauf un truc perso) que des serveurs jetables et je ne m'y connecte en général… jamais. Ça résout le problème :-)
        
        À mais je ne parle que de serveur perso ;) J'ai pas besoin d'un orchestrateur pour mes besoins perso et j'ai pas envie de manipuler docker-compose à travers ansible. SSH fais bien le taff (d'autant que c'est un bon couteau suisse pour avoir un tunnel ponctuellement par exemple).
        
        https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
# merci !

Posté par oau le 25/03/20 à 07:42. Évalué à 2.

Bonjour Etienne,

merci pour ton travail, j'utilise avec plaisir powerline.bash depuis un petit peu plus d'un an. J'ai simplement, un peu à l'arrache, ajouté mon namespace kubernetes.

merci à toi

oau
- [^] # Re: merci !
  
  Posté par Étienne BERSAC (site Web personnel) le 25/03/20 à 08:50. Évalué à 2.
  
  Merci :-) Je suis intéressé par ton segment kubernetes. Quand tu veux pour une MR :-)
  - [^] # Re: merci !
    
    Posté par Psychofox officiel ✅ 🏖️ le 26/03/20 à 08:08. Évalué à 3.
    Moi j'utilise cette fonction pour avoir le contexte kubernetes :
```
function kubernetes-context()
{
    local KUBERNETES_CONTEXT=$(kubectl config current-context)
    local HAS_NAMESPACE=$(kubectl config view -o jsonpath='{.contexts[?(@.name == "'"$KUBERNETES_CONTEXT"'")].context.namespace}')
    local NAMESPACE=${HAS_NAMESPACE:-default}

    printf $KUBERNETES_CONTEXT[$NAMESPACE]
}
```
    Et après je joue avec les couleurs en fonction des clusters en questions (production ou pas).
    - [^] # Re: merci !
      
      Posté par oau le 26/03/20 à 15:11. Évalué à 2.
      
      merci, j'ai ajouté ça dans ma config et j'ai envoyé une MR à Étienne.
      
      Bonne journée.
  - [^] # Re: merci !
    
    Posté par oau le 26/03/20 à 08:50. Évalué à 2.
    
    elle t'attend :)
# conda

Posté par eingrossfilou le 25/03/20 à 09:55. Évalué à 0.

J'ai testé pour remplacer mon powerline-go moins customisable, et ça à l'air de bien fonctionner en plus de me faire découvrir le retour la ligne avant l'invite de commande.

Néanmoins, je ne basculerais pas pour l'instant. J'utilise beaucoup les environnements conda (miniconda/anaconda), qui ne sont pas pris en charge contrairement aux env python (pour l'instant, j'ose espéré qu'ils le seront dans un futur proche).

Sinon bravo, continuez comme ça.
- [^] # Re: conda
  
  Posté par Étienne BERSAC (site Web personnel) le 25/03/20 à 14:52. Évalué à 2.
  
  les environnements conda (miniconda/anaconda), qui ne sont pas pris en charge
  
  Je suis ouvert aux contributions. Je n'utilise pas conda. N'hésite pas à ouvrir un ticket pour discuter de ce besoin.
- [^] # Re: conda
  
  Posté par Étienne BERSAC (site Web personnel) le 26/03/20 à 15:24. Évalué à 3.
  
  Peux-tu tester le patch https://gitlab.com/bersace/powerline.bash/-/merge_requests/28 ?
  - [^] # Re: conda
    
    Posté par eingrossfilou le 28/03/20 à 11:00. Évalué à 1.
    
    Salut
    
    La modification focntionne pour moi.
    Je dirai s'il y a un pb à l'usage
    
    En tout cas, super réactivité.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.