Liquid Prompt 1.9

Posté par  (site web personnel) . Édité par Benoît Sibaud, Nÿco et Nils Ratusznik. Modéré par patrick_g. Licence CC By‑SA.
39
14
nov.
2014
Ligne de commande

Le Liquid Prompt est un prompt fluide affichant de manière limpide des informations utiles là où vous les verrez : le prompt de votre shell bash ou zsh. Le liquidprompt était déjà bien rempli de fonctionnalités, mais celles-ci ont été stabilisées et leurs performances améliorées durant les mois écoulés. Il était temps de sortir une nouvelle version officiellement stable.

Pour les détails de cette version surtout composée de correctifs (indicateurs de batterie, température, charge processeur, nom de machine, gestion de code source, chemin, prompt, horloge, etc.) ; les curieux sont invités à consulter le fichier CHANGES : Battery indicator, Temperature indicator, CPU load, Hostname, VCS (Git, Fossil, Subversion, Bazar, Mercurial), Analog clock, etc.

Je profite de cette dépêche pour remercier chaudement les 15 contributeurs qui par leurs patchs ont contribué à cette version : Anthony Gelibert, Frédéric Mahé, Panayiotis Kkolos, Étienne Deparis, François Schmidts, Linus Wallgren, Alexander Belaev, Bartosz Janda, Brett McBride, Chase Colman, Cosmin L. Neagu, Matthew Micene, Vincent Lara, Wilson Maravilha et Yannack. Mais aussi tous ceux qui ont signalés des bogues ou proposé des patchs refusés ou en attente.

Copie d'écran de Liquid Prompt

Aller plus loin

  • # Beau boulot !

    Posté par  (site web personnel) . Évalué à 4.

    Merci pour ce prompt qui allie très bonne performance et fonctionnalités !
    C'est le premier git clone que j'effectue sur toutes mes machines.

  • # rapprochement avec Powerline

    Posté par  . Évalué à 2.

    Je remarque que ton projet est très proche de Powerline… mais comporte des features + intéressantes et inversement.

    Il y a-t-il des rapprochements à envisager même si Powerline est dev en python…

    • [^] # Re: rapprochement avec Powerline

      Posté par  (site web personnel) . Évalué à 4.

      La prochaine génération de Liquid Prompt sur laquelle je (l'auteur de la dépêche et le mainteneur de Liquid Prompt) travaille, c'est The Angel's Prompt qui est écrit en Perl, est bien mieux architecturé que Powerline et Liquid Prompt (pour être plus performant), et bien plus puissant et plus polyvalent (ce n'est pas just un prompt mais un moteur de prompt).

      Mainteneur de LiquidPrompt - https://github.com/nojhan/liquidprompt

      • [^] # Re: rapprochement avec Powerline

        Posté par  . Évalué à 2.

        Et du coup LiquidPrompt il est écrit en quoi lui (désolé, mon proxy d'entreprise bloque GitHub) ?

        • [^] # Re: rapprochement avec Powerline

          Posté par  . Évalué à 3.

          En shell.

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • # Démon?

    Posté par  (site web personnel) . Évalué à 8.

    Je viens de regarder rapidement les sources, et j'ai l'impression que comme pour beaucoup d'outils pour le shell, tout est évalué au moment de l'affichage du prompt.

    Je me dis que le shell en tant qu'outil pourrait grandement bénéficier d'un démon qui soit commun à tous les shells ouverts sur la machine. Ce démon pourrait:

    1. Améliorer les performances, en évitant de lancer moult processus à chaque affichage du prompt, et en cachant les informations qui s'y prêtent.
    2. Améliorer la coopération entre les différents shells, par exemple en permettant de centraliser l'historique des commandes en temps réel
    3. Simplifier grandement l'implémentation d'outils comme autojump qui ont besoin de ce genre de stockage centralisé.

    Est-ce que ça vous parait une bonne idée? Quelqu'un y a sûrement pensé avant moi?

    • [^] # Re: Démon?

      Posté par  (site web personnel) . Évalué à 4.

      Ouaip, certain y ont déjà pensé notamment le mainteneur de liquidprompt lui même. Par contre en bash c'est un peu compliqué comme histoire du coup il travail là dessus dans un autre dépôt : https://github.com/dolmen/angel-PS1

      • [^] # Re: Démon?

        Posté par  (site web personnel) . Évalué à 1.

        Et au passage, celui qui y a pensé, c'est moi-même, Olivier Mengué, qui suis à la fois le mainteneur actuel de Liquid Prompt (et l'auteur de la dépêche) et donc aussi l'auteur de The Angel's Prompt (angel-PS1).

        The Angel's Prompt n'est pas un démon, mais un ange ;) Il est écrit en Perl avec un système de plugins qui permet une modularité que n'a pas Liquid Prompt. Le moteur est désormais stable. Le travail est en cours pour porter petit à petit les fonctionnalités de LiquidPrompt. C'est malheureusement un peu en sommeil ces derniers mois car mon temps de cerveau disponible s'est fortement réduit en raison de bonheurs familiaux.

        Comme il s'agit d'un moteur de prompt, il est possible de l'utiliser pour faire son prompt avec des fonctionnalités différentes de Liquid Prompt. Il est par exemple possible de l'utilier pour implémenter un prompt à la Powerline, mais avec des performances bien meilleures (au moins 10x car on ne lance pas Python à chaque affichage du prompt). Exemple (voir examples/Powerline-basic.PS1) :

        git clone https://github.com/dolmen/angel-PS1.git
        cd angel-PS1
        eval $(perl -Ilib bin/angel-PS1 -c examples/Powerline-basic.PS1 )
        

        De plus Liquid Prompt ne fonctionne qu'avec bash et zsh. The Angel's Prompt est lui implémenté de façon indépendante du shell (à part quelques dizaines de lignes spécifiques à chaque shell localisées dans des plugins). Ceci permet d'avoir un prompt très évolué même dans des shells basiques.

        Concernant la gestion de l'historique ça reste le domaine du shell et pas celui de The Angel's Prompt. Si vous voulez un shell avancé au niveau de ses fonctionnalités interactives, je recommande fish, avec lequel The Angel's Prompt est bien sûr compatible.

        Mainteneur de LiquidPrompt - https://github.com/nojhan/liquidprompt

        • [^] # Re: Démon?

          Posté par  . Évalué à 3.

          The Angel's Prompt n'est pas un démon, mais un ange ;)

          C'est un vrai point technique ou juste de l'humour ?

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

          • [^] # Re: Démon?

            Posté par  . Évalué à 2.

            Lisant le readme, je vote pour humour.

        • [^] # Re: Démon?

          Posté par  . Évalué à 2.

          Pour l'histoire des performances : tu ne lances pas Python mais Perl si je comprend bien : c'est remplacé un langage de script par un autre? Si oui, le rapport de 10 est un peu exagéré, non?

          • [^] # Re: Démon?

            Posté par  . Évalué à 3.

            La question n'est pas de savoir quelle est la performance des langages en question, mais le fait de ne pas lancer systématiquement un nouveau processus.

            Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

    • [^] # Re: Démon?

      Posté par  . Évalué à 3.

      À noter que la centralisation de l'historique est déjà prise en charge par zsh (sans daemon, que je sache).

      • [^] # Re: Démon?

        Posté par  . Évalué à 4.

        C'est possible avec bash (mais c'est moche) http://unix.stackexchange.com/questions/1288/preserve-bash-history-in-multiple-terminal-windows

        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

      • [^] # Re: Démon?

        Posté par  . Évalué à 4.

        À propos de la centralisation de l'historique… Qui trouve ça utile ?

        J'ouvre généralement pas mal de terminal, un par activité en gros. Quand j'ai besoin de remonter dans l'historique, j'ai systématiquement besoin de l'historique du terminal courant, pas des autres. Donc j'ai désactivé l'historique global.

        En revanche j'aime bien que tout ce retrouve dans l'historique une fois le terminal fermé, pour la prochaine fois que j'aurais à faire un truc du genre. C'est finalement un peu comme des alias qui disparaissent quand je ne les utilise plus.

        Please do not feed the trolls

        • [^] # Re: Démon?

          Posté par  . Évalué à 6.

          Qui trouve ça utile ?

          Moi !

          J'ouvre généralement pas mal de terminal, un par activité en gros. Quand j'ai besoin de remonter dans l'historique, j'ai systématiquement besoin de l'historique du terminal courant, pas des autres. Donc j'ai désactivé l'historique global.

          Chez moi à la sortie d'une commande, l'historique n'est pas remis à jour tout de suite ce qui est très pratique pour faire flèche haut > Entrée pour relancer la même commande par exemple.

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

        • [^] # Re: Démon?

          Posté par  . Évalué à 2.

          Moi
          Principalement pour la recherche de commandes (CTRL+R).

    • [^] # Re: Démon?

      Posté par  . Évalué à 2.

      J’ai un prompt personnalisé depuis 2005, je suis très loin de ce qui est présenté ici, mais ça marche pas mal.
      Au départ, je recalculais tout tout le temps, et le prompt finissait par s’afficher en 2s, très énervant. Finalement, la solution que j’ai appliquée, c’est une variable MYPROMPT mise à jour à chaque commande cd. L’optimisation du script à également aidé.

      Mon prompt ressemble à ça :

      login:[AJa]/.../rép1/rép2/rép3 [RW] $
      
      login:[AJa]/...pertoire_trop_long/rép3 [RW] $

      Le login est géré par bash, le [AJa] est un remplacement réaliser par des expressions régulières. Construit à partir de ls /home puis un finger et un sed ou awk pour récupérer le tri-gramme. Les expressions régulière sont dans un fichier de conf. Ensuite on affiche entre 1 et 3 (personnalisable) répertoire mais avec un maximum de 40 caractère.

      Le RW s’affiche en vert ou rouge en fonction des droits d’écriture dans le répertoire courant.

      Le calcul de la deuxième partie est faite par la commande cd qui est une fonction appelant le builtin cd.

      Je m’étais également ajouté une commande xcd allant chercher dans mon fichier d’expression régulière pour aller directement dans le répertoire associé.

      login:[AJa]/.../rép1/rép2/rép3 [RW] $ xcd AJa
      login:[AJa]/ [RW] $

      Le tout compatible GNU/Linux, SUN et HPUX. Enfin, à l’époque…

  • # Avoir de l'aide ?

    Posté par  (site web personnel) . Évalué à 1.

    Bonjour,
    Quelqu'un sait-il comment on demande de l'aide ? Sur GitHub, je vois comment on remonte un bug, mais tel n'est pas mon besoin…
    Mon problème est le suivant : le README dit que liquidprompt s'adapte au passage de simple utilisateur à root, je ne sais comment ; quand je fais "su - root", je perds les fonctionnalités de liquidprompt. Cela fonctionne-t-il par passage de variables d'environnement (auquel cas peut-être "su root" fonctionnerait…) ?

    • [^] # Re: Avoir de l'aide ?

      Posté par  . Évalué à 2.

      Il faut que tu définisses ton PS1 dans le bashrc de root, où dans le bashrc général (/etc/bashrc). S’il est dans le général, il faut peut-être ajouter une ligne du genre : . /etc/bashrc dans /root/.bashrc histoire de mettre à jour ton environnement shell.

      • [^] # Re: Avoir de l'aide ?

        Posté par  (site web personnel) . Évalué à 1.

        Merci Anthony! Quelle valeur dois-je mettre dans la variable PS1 (que je valoriserai dans /etc/bashrc) ?

        • [^] # Re: Avoir de l'aide ?

          Posté par  . Évalué à 2.

          Il semble que liquid prompt te fournisse un script qui fait ça seul. Il faut donc « sourcer » liquidprompt.
          Je reprends ci-dessous le exemple.bashrc :

          # if you want to use the liquidprompt without bothering about its configuration,
          # just:
          # cp example.bashrc ~/.bashrc
          # This part is a minimalist bash config file example
          # Use the system config if any
          if [ -f /etc/bashrc ]; then
          . /etc/bashrc # --> Read /etc/bashrc, if present.
          fi
          # Use bash completion, if installed
          if [ -f /etc/bash_completion ]; then
          . /etc/bash_completion
          fi
          # If you have your own config for the liquid prompt, edit and uncomment this line:
          # source /path/to/liquidpromptrc
          # Use the liquidprompt
          source ~/.liquidprompt

          Les dernières lignes doivent être dans tes bashrc. Soit directement une fois sous le home de ton utilisateur, et une pour ton root. Soit une seule fois dans /etc/bashrc pour tous les utilisateurs à condition d’avoir les lignes : if [ -f /etc/bashrc ];… pour chaque utilisateur voulant l’utiliser.

          Si tu mets la modification dans le /etc, pense bien à mettre le chemin complet vers le script liquidprompt car le raccourcis ~ est différent en fonction de l’utilisateur.
          Après, je ne l’ai même pas essayé car je trouve qu’il y a trop d’info sur le screenshot et que mon prompt actuel me convient.

          J’espère avoir été clair, mais si tu ne connais pas le shell c’est peut-être encore obscur…

          • [^] # Re: Avoir de l'aide ?

            Posté par  (site web personnel) . Évalué à 1.

            OK, j’avais vu le bashrc exemple, mais rien sur PS1, d’où mon doute… Merci pour la clarification. Pas d’inquiétude, je maîtrise le shell, c’est juste liquidprompt que je découvre ;-)

            • [^] # Re: Avoir de l'aide ?

              Posté par  (site web personnel) . Évalué à 0.

              Pas d’inquiétude, je maîtrise le shell,

              Je te conseille de réviser un peu pour que tu comprennes pourquoi le "sudo" te fait perdre le prompt. "sudo" est une commande qui lance elle-même un shell. Et les variables/fonctions de liquidprompt ne peuvent être propagées d'un shell à l'autre.

              Mainteneur de LiquidPrompt - https://github.com/nojhan/liquidprompt

              • [^] # Re: Avoir de l'aide ?

                Posté par  . Évalué à 5.

                Et les variables/fonctions de liquidprompt ne peuvent être propagées d'un shell à l'autre.

                C'est faux. Quand on veut donner des leçons, faut être rigoureux.

                Je te conseille de réviser un peu sudo et l'option -E par exemple. Donc il peut même si par défaut il ne le fait pas.

                Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

      • [^] # Re: Avoir de l'aide ?

        Posté par  (site web personnel) . Évalué à 1.

        Bon, après vérification, j’avais déjà essayé ça…
        Comme la configuration est dans /etc/liquidpromptrc et l’exécutable est /usr/bin/liquidprompt dans Arch Linux, du coup, je n’ai rien de particulier dans le HOME-directory. Le seul changement que j’ai fait en tant qu’utilisateur, c’est d’ajouter l’unique ligne suivante à mon ~/.bashrc:
        . /usr/bin/liquidprompt

        Le problème, c’est que j’ai fait de même dans le .bashrc de root et malgré ça je perds liquidprompt quand je fais « su - root » ; je ne perds pas liquidprompt quand je fais « su root » par contre.

        Autre « problème » : screen ou tmux n’est semble-t-il pas détecté.

        Bref, je ne suis pas sûr que LinuxFR soit l’endroit idéal pour poser ces questions sur liquidprompt, d’où ma question initiale : y a-t-il un email, une mailing-list, un canal IRC, un salon Jabber ?

        • [^] # Re: Avoir de l'aide ?

          Posté par  (site web personnel) . Évalué à 2.

          Un e-mail : dolmen arobase cpan point org (mais tu aurais pu le trouver dans les logs Git)
          Un cannal IRC : #angel-PS1 sur irc.perl.org (mais je n'y suis pas beaucoup en ce moment)

          Sinon, il n'y a aucun problème à utiliser les issues Github pour des questions de support, y compris en français.

          Mainteneur de LiquidPrompt - https://github.com/nojhan/liquidprompt

        • [^] # Re: Avoir de l'aide ?

          Posté par  (site web personnel) . Évalué à 3.

          ça je perds liquidprompt quand je fais « su - root » ; je ne perds pas liquidprompt quand je fais « su root » par contre.

          Tu ne perds pas liquidprompt, c’est l’inverse qui se passe : tu ne le relances pas à l’ouverture d’une nouvelle session vierge.

          sudo ou pas, c’est le sens du message de Dolmen plus haut. C’est une notion fondamentale, si tu lances un shell de login avec un nouvel utilisateur, son environnement est le sien, pas le tien, donc il est normal et il faut que certaines informations ne soient pas propagées entre les deux sessions.

          Il y a des astuces pour ouvrir un shell sous un autre utilisateur en conservant l’environnement, via sudo justement, mais donc si tu n’utilises pas sudo ou autre outil de ce type, ce que Dolmen dit est d’autant plus vrai. Il est normal et il faut qu’en ouvrant une nouvelle session utilisateur cette session soit différente de celle des autres utilisateurs.

          Ce qu’il te faut faire, c’est soit configurer chaque utilisateur pour utiliser liquidprompt, soit configurer le système pour que tous les utilisateurs utilisent liquidprompt.

          ce commentaire est sous licence cc by 4 et précédentes

    • [^] # Re: Avoir de l'aide ?

      Posté par  . Évalué à 3.

      Dans la page de man de su :

      For backward compatibility su defaults to not change the current directory and to only set the environment variables HOME and SHELL

      Le shell lancé sous root va chercher son fichier de conf dans $HOME/.bidulerc, autrement dit ~root/.bidulerc, alors que ton prompt liquid prompt est vraissemblablement mis en place dans ~user/.bidulerc

      Dans su tu a l'option -p qui fait ça, ça ne touche à aucune des variables d'environnement, mais ça va poser des problèmes…

      Le plus simple serait que tu install liquid prompt pour root aussi ou que tu mette un symlink de ton .bidulerc vers celui de root.

      Please do not feed the trolls

Suivre le flux des commentaires

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