Je suis passé à Powerline pour mon Bash

Cet article a été publié il y a 5 ans 8 mois 8 jours, il est donc possible qu’il ne soit plus à jour. Les informations proposées sont donc peut-être expirées.

Après des années à voir passer des articles sur des configurations spécifiques pour bash, et plus récemment sur fish, que des collègues utilisent au boulot (les mac eux bossent sur zsh), je me suis dit qu’il faudrait aller un peu plus loin que mon bash classique à peine modifié pour inclure git. Ça n’a pas été de tout repos, j’ai pas mal tâtonné mais j’arrive à quelque chose qui me plaît.

Première tentative : powerline.bash

J’ai vu passer le script sur le Journal du Hacker, ça m’a plu très vite : pur bash, léger, on clone, on source et ça juste marche. A peu de chose près, car il faut avoir une police adaptée comme pour Powerline, j’ai procédé comme suit :

Ça, c’était chez moi, et dans l’ensemble ça fait le taf. Là où ça coince, c’est en arrivant sur ma vm Lubuntu du boulot, j’ai un problème disqualifiant avec la complétion SSH. Le problème est très exactement décrit dans une issue mais pas de réponse pour l’instant il est pris en charge maintenant qu’il a reçu les notifications 🙂 Je reproduis sur deux variantes fraîchement installées d’Ubuntu. Avec un comportement encore pire sur Ubuntu car les polices ne sont pas prises en compte comme il faut, donc on a des trucs biens dégueu sur les séparations. Un debug à base de bash +x ne donne rien de flagrant. Je reviens en arrière et cherche un peu, mais je suis déjà frustré.

UPDATE : Comme quoi la contribution ça tient à peu de chose, une petite remontée rapide, et hop, le problème de complétion SSH est maintenant corrigé 🙂

Finalement, rien de tel que l’original : Powerline

Ce qui était sympathique avec ça, c’est que c’est ultra léger. Powerline de son côté est écrit en python, nécessairement plus complexe. L’installation est cependant encore plus simple puisque le soft est empaqueté et présent dans la plupart des distributions. Il y a quelques subtilités notamment les paquets de polices adaptées dont le nom change. En effet, si c’est fonts-powerline sur Ubuntu et dérivés, c’est powerline-fonts sur Arch/Manjaro.

NB : au départ Powerline est prévu pour « pimper » Vim, mais des plugins sont vite venus se greffer dessus pour ajouter le support des différents shells.

L’activation elle par contre est un peu plus roots. On commence par créer le dossier ~/.config/powerline qui va contenir nos différents éléments de configuration, et vous allez voir qu’il en faut potentiellement beaucoup plus. Au début je la joue simple, j’utilise juste le thème default_leftonly qui inclue le segment pour git. Il faut pour ça juste ajouter le bout de json « kivabien » dans le fichier config.json :

Reste ensuite à ajouter les lignes suivantes dans un bashrc, bash_aliases, ou encore .extend.bashrc en fonction de votre distribution pour activer le bousin :

Un source plus tard, dites bonjour au prompt :

Problème, même en jouant avec les options du segment, je ne vois pas l’état du dépôt courant, juste la branche. Au moins avec powerline.bash la couleur changeait pour dire qu’il y avait du taf en cours.

En cherchant une autre solution je tombe sur gitstatus, un segment personnalisé spécial pour git. Installation simple aussi, puisque le module s’installe via pip. Sa configuration par contre c’est beaucoup plus touffu, d’où ma remarque un peu plus tôt. Je suis la documentation plus ou moins à la lettre, je m’explique. Il faut d’abord créer le profil de couleur pour toutes les infos qu’il va afficher. Ensuite, et c’est là que c’est pas forcément clair, il faut créer une copie du thème par défaut pour y inclure le segment gitstatus, sinon il n’est pas pris en compte. Et comme c’est un ajout au thème par défaut, finalement virer mon fichier config initial puisque on rebascule dessus.

En rechargeant le tout c’est beaucoup plus intéressant côté git :

Certes il va maintenant falloir prendre l’habitude de la signalétique mais on sait tout de suite dans quel état se trouve le dépôt.

Une doc à fouiller

J’avais modifié mon rôle Ansible maison de déploiement utilisateur pour exploiter la version en bash, puis pour la première version en Python; mais il va falloir encore un peu plus de taf pour celui-ci, car on voit que le boulot est plus conséquent. Comme je l’ai dit, la doc Ansible est un bonheur, et il y a un module pip qui va permettre de faire les choses proprement.

Il y a en effet pas mal d’options à creuser, j’ai déjà un truc qui va bien, mais il est possible d’aller un poil plus loin, donc on va bosser un peu le site dédié même si le niveau de détails est loin d’égaler la doc d’Ansible. Je cherche notamment à finalement bosser sur deux lignes, j’ai vu ça sur la version bash et ça m’a plu direct. Affaire à suivre donc. Apparemment c’est faisable mais c’est pas aussi simple que ça parait.

Warning sur Arch/Manjaro

En fait la routine d’inclusion au bashrc avait du être adaptée quand je l’ai installé sur le laptop. Pour une raison que j’ignore, le fichier powerline.sh à inclure se trouvait dans le dossier d’installation de Python, /usr/lib/python3.6/site-packages/powerline/bindings/bash/powerline.sh, et pas celui de la documentation (qui est faux aussi pour Debian/Ubuntu soit dit en passant). En tout cas je l’ai trouvé là, du moins updatedb/locate me l’a montré à cet endroit-là.

Oui mais entre temps, petite mise à jour (370 paquets…), et surprise, Python 3.7 est de sortie. Du coup le chemin change (étrangement je retrouve celui que je vous ai partagé), et le paquet gitstatus doit être réinstallé pour la nouvelle version. Faudra juste s’en souvenir lors de l’arrivée de Python 3.8 🙂

D’autres options pour avoir un shell plus « musclé »

J’ai volontairement fait le choix de rester mesuré sur les ajouts que je fais sur Bash. J’ai également fait le choix de rester sur Bash, parce que si sur le laptop je fais ce que je veux, quand je suis sur les serveurs des clients je ne maîtrise pas tout, et en particulier nos prérequis système s’appuie sur le shell par défaut des distributions qu’on utilise, et donc CentOS utilise Bash, tout comme Debian. Je préfère donc éviter de trop diverger.

J’évoque notamment Fish en introduction, c’est l’exemple parfait de divergence qui rend service mais qui peut desservir aussi quand on n’y a plus accès. Notamment en matière de scripting. C’est donc un outil qu’il faut analyser vraiment en détail avant de vouloir s’en servir.

Dans une optique plus mesurée, j’avais déjà pu dans le passé tester rapidement liquidprompt. Ça vient se greffer sur Bash comme Powerline, et les options d’affichage sont aussi nombreuses, même plus que pour Powerline. Mais ça ne m’avait pas emballé à l’époque, peut-être le design, ou alors c’était trop tôt pour moi.

D’ailleurs liquidprompt est aussi exploitable sur Zsh, mais j’en connais qui l’utilisent plutôt avec Oh My Zsh, qui exploite à fond les capacités de personnalisation de Zsh pour proposer une expérience qui déboîte à ce qu’il paraît. Plusieurs collègues au boulot, notamment ceux qui bossent sur Mac, l’utilisent de cette façon, du fait que Zsh et Bash partagent pas mal de similarités (plus qu’avec Fish), je me laisserai peut-être tenter un jour. Avec toujours ce problème qu’il n’est pas toujours possible de l’exploiter sur les serveurs des clients, ce qui oblige donc à garder les bases en mémoire.

Ce sont les options les plus connues je pense. Mais si vous connaissez d’autres options pour avoir une ligne de commande qui rox du poney, n’hésitez pas à partager, je suis certain que vous avez tous vos petites astuces concernant votre shell préféré. Et je serais curieux de les connaître 🙂