Liquidprompt version 1.7

Posté par  (site web personnel, Mastodon) . Édité par Benoît Sibaud et Nils Ratusznik. Modéré par Nils Ratusznik. Licence CC By‑SA.
Étiquettes :
42
2
déc.
2013
Technologie

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 vu la quantité de travail de fond accompli sur la branche de développement, il coulait de source qu'il était temps de sortir une nouvelle version stable.

Une vague de bugfix (notamment une meilleure compatibilité avec zsh, FreeBSD, OpenBSD et OS X) mais surtout un torrent, que dis-je, un raz-de-marée, d'optimisations (notamment dans les dépôts mercurial ou bazaar) écoulées par le nouveau mainteneur, Olivier Mengué.

Quelques gouttes de fonctionnalités, également :

  • affichage du temps mis par la dernière commande (s'il dépasse un seuil, dans le plus pur style liquidprompt) ;
  • l'affichage du nombre de lignes modifiées dans les dépôts fossil ;
  • la température affichée est maintenant la moyenne des maximums ;
  • désactivation du support de gestion de version pour l'utilisateur root (plus logique d'un point de vue sécurité).

Je ne voudrais pas trop me mouiller, mais je crois qu'on a là un excellent cru.

Aller plus loin

  • # liquide, quoi...

    Posté par  . Évalué à 10.

    Excellente dépêche et bravo pour le style d'écriture, je veux dire que tu as surnagé l'ensemble des autres dépêche là ;)

  • # Gracias

    Posté par  (site web personnel) . Évalué à 7. Dernière modification le 02 décembre 2013 à 10:50.

    Utilisateur satisfait, j'adresse un gros merci à l'équipe de développement, on peut parfois se noyer dans tout un tas de bout de scripts pour confectionner son .bashrc et ce logiciel est une vraie bouée de sauvetage pour moi.

  • # température

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

    la température affichée est maintenant la moyenne des maximums

    L'inverse, la température affichée est maintenant la plus élevées des températures lues. Cela permet de ne pas ignorer une température anormalement haute au cas où on aurait un grand nombre de sondes qui renverraient un grand nombre de résultat et donc une moyenne qui resteraient relativement stable même si une valeur s'envole.

  • # Bah zut, pourquoi moi ça marche pas directement :'(

    Posté par  . Évalué à 1.

    j'ai fait un git clone dans mon dossier ~/bin, puis j'ai ouvert un terminal (j'utilise bash) placé sur ~, et un "source bin/liquidprompt/liquidprompt".

    et là paf, pastèque : ""bash: 82/ : erreur de syntaxe : opérande attendue (le symbole erroné est "/")

    par contre, j'ai quand même un liquidprompt qui semble correct, mais toujours le même message à chaque commande.

    je vous donne un retour si j'ai des news (je suis sur archlinux dernière maj et openbox au fait)

  • # Hum... Les remote repository c'est pas top

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

    En gros, chaque fois que je vais dans un répertoire avec un dépot HG qui est lié à un dépôt distant, cela prend du temps ET cela me demande un password ;( Il faudrait juste un élément de config pour pas qu'il s'amuse à vérifier à chaque fois, je m'en cogne un peu de savoir en permanence que je suis sync ou pas sur le dépot distant.

    Sinon j'aime bien, sauf que j'ai désactivé les VCS pour l'instant.

    • [^] # Re: Hum... Les remote repository c'est pas top

      Posté par  (site web personnel) . Évalué à 3. Dernière modification le 02 décembre 2013 à 17:56.

      Pour éviter de virer complètement toute la gestion VCS, tu peux donner un ou plusieurs répertoires VCS à ignorer dans ton .liquidpromptrc, c'est d'ailleurs le problème que j'avais en accédant à un mount ssh d'un répertoire svn à une époque : 

      \# Specify a list of complete and colon (":") separated paths in which, all vcs
\# will be disabled
LP_DISABLED_VCS_PATH=""

  • # Bug

    Posté par  . Évalué à 3.

    A chaque commande, ca m'affiche cela :

    bash: history: -; : option non valable
    history : utilisation :history [-c] [-d décalage] [n] ou history -anrw [nomfichier] ou history -ps arg [arg…]

    Je suis sous Mageia 3. Une idée ?

    • [^] # Re: Bug

      Posté par  . Évalué à 2.

      J'aime le même problème sous une vieille Mandriva.

      Chez moi, le script
      /etc/profile.d/95bash-extras.sh
      modifie la variable PROMPT_COMMAND pour y insérer un
      history -a;
      au début.

      Elle est donc égale à
      history -a; echo -ne "\033]0;${USER}@${HOSTNAME%%.*}:${PWD/#$HOME/~}"; echo -ne "\007"

      J'ai donc modifié dans liquidprompt la ligne
      Linux|FreeBSD|OpenBSD|SunOS) $LP_OLD_PROMPT_COMMAND ;;
      par
      Linux|FreeBSD|OpenBSD|SunOS) eval $LP_OLD_PROMPT_COMMAND ;;

      Pour gérer un peu mieux ce cas-ci.

      Je te laisse faire le rapport de bug ;)

  • # Perf

    Posté par  . Évalué à 6.

    Avez vous regardé un peu l'écart de perf entre l'approche de liquiprompt de tout faire en shell et les choix fait par d'autres projets similaires de lancer un script python ou autre pour générer le PS1 ?

    Pour avoir lu le code des deux, l'approche shell est beaucoup plus complexe et bordelique, mais sur des petites config je me demande la différence de confort à l'usage. Sur une machine actuelle lancer du python ne pose aucun soucis. Donc tout se joue sur les vieux trucs pourris.

    • [^] # Re: Perf

      Posté par  . Évalué à 2.

      j'ai teste different truc pour changer PS1 pour git et en resume c'est rapide si le projet n'est pas trop gros mais ca ralenti enormement des que tu as un gros projet. Donc en gros ce genre de chose c'est super pratique mais a ne pas utiliser avec tout.

      Par contre que ce soit bash ou python le cote lent c'est surtout l'appel git donc cela ne change rien ou si peu.

      • [^] # Re: Perf

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

        l'appel git donc cela ne change rien ou si peu.

        ça doit dépendre aussi comment ça fonctionne (je n'ai pas regardé pour liquidprompt)
        Car avec git il y a deux moyens d'avoir les infos :

        1. lancer des commandes git et parser le résultat -> lent et mauvaise solution la plupart du temps
        2. aller lire le .git ce qui se fait avec du grep, sed, awk, … et qui est tout de suite moins lent

        • [^] # Re: Perf

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

          aller lire le .git ce qui se fait avec du grep, sed, awk, … et qui est tout de suite moins lent

          J'ai hâte de voir la démonstration de cette assertion qui ne porte pas en elle les preuves de sa véracité :-)

          • [^] # Re: Perf

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

            $ time git branch
* bla
  master
hub branch  0,09s user 0,02s system 96% cpu 0,118 total

            $ time cat .git/HEAD
ref: refs/heads/bla
cat .git/HEAD  0,00s user 0,00s system 77% cpu 0,003 total

            Sachant que dans les deux cas il va falloir parser la sortie pour extraire réellement la bonne présentation.

            Comment ça c'est pas une belle démonstration ?
            Je dis pas qu'on peut tout faire avec. Mais une partie oui. Les commandes git sont faites pour l'utilisateur, pour le reste il est souvent plus intéressant de descendre dans les commandes bas niveau de git ou même .git.

            • [^] # Re: Perf

              Posté par  . Évalué à 2.

              Je n'ai personnelement pas trouve un seul projet qui fait cela en utilisant les outils shells. Et meme comme cela pour l'enorme majorite des depots ca doit etre invisibles par contre avec des projets comme Qt ou le kernel la on voit la probleme.

      • [^] # Re: Perf

        Posté par  . Évalué à 4.

        Par contre que ce soit bash ou python le cote lent c'est surtout l'appel git donc cela ne change rien ou si peu.

        Si je pose la question c'est pas pour rien.

        Le fait que les differents modules puissent etre lent et que certains doivent être desactivés selon l'environement c'est une évidence (j'ai "contribué" le module le plus lent de liquidprompt).

        Par contre, contrairement à ce que tu dis, forker un python à chaque PS1 ca à un coup non négligable sur du vieux matos. Essaie sur le premier eeepc par exemple, tu vas voir la réactivités du truc. La question c'est à partir de quel hardware ca ne gène plus ton flot de travail. Sachant que si avec une approche sheel tu es obligé de virer tout les modules intéressant sur une petite config, autant pas se faire chier à utiliser une techno compliquée vu que de toute facon tu gagnes rien…

        On peut aussi imaginer une approche hybrique avec un processus résidant et faire de l'IPC pour éviter le cout de lancement de l'interpreteur.

        Liquidprompt c'est cool, mais quand tu compares le code à celui d'un powershell-line tu te dis qu'il y a un monde. C'est pas très grave vu que c'est petit et que ca bouge pas trop. Mais techniquement ca m'intéresse si quelqu'un y a déjà réfléchi.

        • [^] # Re: Perf

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

          C'est plutôt l'approche avec un processus séparé qui était envisagé je pense. C'est d'ailleurs l'idée derrière un autre projet du deuxième mainteneur du projet (mais en Perl) : angel-PS1.

    • [^] # Re: Perf

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

      Avez vous regardé un peu l'écart de perf entre l'approche de liquiprompt de tout faire en shell et les choix fait par d'autres projets similaires de lancer un script python ou autre pour générer le PS1 ?

      Oui, j'ai regardé. Et j'ai été horrifié par les performances de liquidprompt, ce qui m'a initialement amené à contribuer au code pour corriger les trucs les plus évidents, jusqu'à devenir le mainteneur. Le principal problème des projets en shell, c'est que les contributeurs sont très souvent de piètres programmeur shell, et mon boulot est bien souvent de faire le ménage derrière une contribution de fonctionnalité.

      Personnellement, mon environnement de travail perso est un netbook avec 1 Go de RAM que j'utilise dans le RER, donc sur batterie. Donc les perfs, oui, je m'en préoccupe beaucoup. Même si celle de liquidprompt ne me concernent que peu au quotidien (j'ai beau être le mainteneur, je trouve liquidprompt trop verbeux).

      En fait je me préoccupe tant des performances de mon prompt que j'ai commencé en mai 2013 mon propre projet parallèle qui consiste à réaliser un moteur de prompt générique (cross-shell) en Perl 5, sous la forme d'un ange (daemon) résident. Pour en savoir plus : https://github.com/dolmen/angel-PS1 Le cœur du moteur est à peu près prêt. Je suis en train d'écrire les plugins qui permettront d'avoir les fonctionnalités équivalentes de liquidprompt.

      Pour avoir lu le code des deux,

      Quel autre ? PowerLine ?

      Exécuter des programmes durant la composition du prompt provoque des forks et des commutations de contexte. Seul un changement majeur d'architecture logicielle peut réduire cela. C'est mon approche avec The Angel's Prompt.

      l'approche shell est beaucoup plus complexe et bordelique, mais sur des petites config je me demande la différence de confort à l'usage. Sur une machine actuelle lancer du python ne pose aucun soucis. Donc tout se joue sur les vieux trucs pourris.

      Mon but avec The Angel's Prompt est d'allier la performance ET la maintenabilité grâce à un langage de haut niveau très portable.

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

  • # Oh my zsh

    Posté par  . Évalué à 4.

    Personnellement, je lui préfère oh-my-zsh

    • [^] # Re: Oh my zsh

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

      Ces deux projets ne font pas vraiment la même chose. Oh-my-zsh vise plus large, il cherche à configurer l'intégralité du shell.
      On pourrait tout à fait faire un module Oh-my-zsh avec liquidprompt.
      En l'état il n'y a pas d'équivalent aussi intégré et dynamique dans Oh-my-zsh, qui propose surtout (enfin, la dernière fois que j'ai regardé, voilà un an ou deux) des prompts peu contextualisés et très mis en forme.

      • [^] # Oh my fish

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

        Je suis récemment passé au shell fish.
        Je m'y plais bien mais liquidprompt me manque. J'ai essayé oh-my-fish insipiré par oh-my-zsh et c'est loin d'égaler liquidprompt.
        J'ai vu ce début de ré-écriture de liquidprompt pour fish : https://github.com/HarnoRanaivo/liquidprompt/tree/fish mais malheureusement il ne fonctionne pas chez moi.
        C'est fort dommage car j'adore son approche avec les fonctions "lp_enable", "lp_disable" pour paramétrer facilement les fonctionnalités sans taper directement dans le code comme il faut le faire pour oh-my-fish :-/

        • [^] # Re: Oh my fish

          Posté par  . Évalué à 3.

          J'ai toujours eu du mal avec fish parce qu'il ne permet pas (du moins par défaut) d'utiliser les raccourcis ctrl+a, ctrl+e, alt+f, etc c'est possible de les ajouter ? Par rapport à bash/zsh il apporte quoi mis à part la coloration à la frappe ?

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

          • [^] # Re: Oh my fish

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

            Hum, aucune idée, je n'ai jamais utilisé ces raccourcis.
            ctrl+a est ma touche de commande tmux.
            ctrl+e et alt+f ne font rien dans mon fish mais dans mon bash non plus, c'est censé faire quoi?

            Les avantages que je vois à fish:

            • La coloration et la complétion
            • La recherche facile dans l'historique (je tape config puis flèche haut j'ai la dernière commande contenant config)
            • Le tab bien géré (c'est faisable aussi dans zsh, mais dans zsh la config par défaut me plait pas celle de fish me convient), complétion qui fonctionne pour tout (sous Arch j'ai ça dans bash avec le paquet bash_completion, sous debian j'ai jamais réussi à avoir ne serait-ce que la complétion après sudo dans bash)
            • Le raccourcis des paths je le trouve pas idiot (première lettre de chaque dossier sauf le dernier)
            • Des petits détails soignés, genre début d'un mot puis tab m'indique les commandes possibles mais aussi leur description, exemple avec 'mo' : http://pastebin.archlinux.fr/477455
            • le ** à la zsh (qui manque dans bash)
            • un historique des cd, on peut naviguer dedans avec prevd, nextd et dirh permet de le voir
            • ^ permet de rediriger stderr, à la manière de < et > pour stdin et stdout. (^ ^ fonctionne comme << et >>)

            Ce qui est pas cool:

            • Il a pas le même langage donc c'est dangereux de le mettre en shell par défaut (je l'ai juste mis comme shell tmux du coup)
              • Ce langage n'est pas un langage existant (ils auraient pu prendre python, php, perl, ruby, ou un sous-ensemble de l'un deux, ou que sais-je… mais non)
              • Dans ce langage les index de tableaux commencent à 1
            • La configuration est pas bien pratique, ya pas un beau fichier de conf commenté à éditer, le truc de config web est pas pratique et marche pas toujours, donc pour l'instant chuis un peu dans le flou.
            • Comme il lit pas .bashrc faut le traduire, export devient set -x, etc…
            • Ya quelques reflexes à prendre, les fonctions au lieu des alias, set au lieu d'export, …

            Bref, en clair il a de gros avantages sur bash, sur un zsh bien configuré c'est moins sûr.

            • [^] # Re: Oh my fish

              Posté par  . Évalué à 3.

              Hum, aucune idée, je n'ai jamais utilisé ces raccourcis.
              ctrl+a est ma touche de commande tmux.
              ctrl+e et alt+f ne font rien dans mon fish mais dans mon bash non plus, c'est censé faire quoi?

              • ctrl+a positionne au début de la ligne
              • ctrl+e positionne à la fin de la ligne
              • alt+f avance d'un mot
              • ctrl+w supprimer le mot précédent le curseur
              • ctrl+k supprimer la fin de la ligne à partir du curseur
              • alt+. coller le dernier mot de la commande précédente à la positione du curseur
              • ctrl+y coller ce que l'on vient de supprimer

              Ce sont des raccourcis (ce n'est pas exhaustif) par défaut de readline et zle (le gestionnaire de raccourcis de zsh) et c'est utilisable un peu partout (il y a un paquet rlwrap qui permet de les réutiliser pour un shell qui le permettrait pas (qui parle de sqlplus ?)).

              • La coloration et la complétion

              C'est probablement le plus évident.

              • La recherche facile dans l'historique (je tape config puis flèche haut j'ai la dernière commande contenant config)

              Le ctrl+r classique me semble plus agréable (il permet de faire une recherche n'importe où dans les commandes).

              • Le tab bien géré (c'est faisable aussi dans zsh, mais dans zsh la config par défaut me plait pas celle de fish me convient), complétion qui fonctionne pour tout (sous Arch j'ai ça dans bash avec le paquet bash_completion, sous debian j'ai jamais réussi à avoir ne serait-ce que la complétion après sudo dans bash)

              hum, jamais eu de problème avec bash (même si j'utilise zsh).

              • Le raccourcis des paths je le trouve pas idiot (première lettre de chaque dossier sauf le dernier)

              Ça ouai ça existe dans zsh (mais pas en bash apparemment).

              • Des petits détails soignés, genre début d'un mot puis tab m'indique les commandes possibles mais aussi leur description, exemple avec 'mo' : http://pastebin.archlinux.fr/477455

              C'est vrai que c'est sympa et unique.

              • le ** à la zsh (qui manque dans bash)

              Ça s'appelle les globbings étendus et c'est présent dans bash depuis la version 4 (c'est donc partout). Mais je pense que zsh pousse le concept plus loin que les autres sur ce sujet (**/*(.) pour ne lister que les fichiers, (/) pour les dossiers, *() pour le fichiers exécutables, (#i)*e* pour être insensible à la casse,…).

              • un historique des cd, on peut naviguer dedans avec prevd, nextd et dirh permet de le voir

              Quelle est la différences avec pushd/popd ? bash et zsh permet l'autopushd qui fait qu'un cd fait aussi un autopushd. zsh roxx avec cd -n avec n la profondeur du dossier dans la pile, si on fait cd - on voit la pile (et on peut configurer la pile pour éliminer les doublons).

              ^ permet de rediriger stderr, à la manière de < et > pour stdin et stdout. (^ ^ fonctionne comme << et >>)

              bash et zsh font ça avec 2> et 2>> l'avantage c'est que les redirections sont génériques et peuvent servir pour tout descripteur de fichier (ils n'ont pas de mérite ça viens de la famille tcsh/ksh).

              Merci beaucoup pour ton retour sur fish :)

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

              • [^] # Re: Oh my fish

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

                Wow merci des astuces, alt + f fonctionne dans fish et permet d'accepter la complétion proposée mot par mot, pour ne reprendre que le début.
                ctrl+w/y fonctionne aussi.

                Je préférerais quand même trouver un shell qui utilise ctrl + flèche droite/gauche pour se déplacer de mot en mot et ctrl + backspace ou suppr pour supprimer un mot comme c'est le cas dans les éditeurs de texte.

                • [^] # Re: Oh my fish

                  Posté par  . Évalué à 2.

                  Je viens de ré-essayer c'est le alt+. qui m'a manqué.

                  Pour les raccourcis « classiques » (dans le sens que l'on trouve dans les interfaces graphiques), zkdb/zle permettent de le faire, mais faut prendre un peu de temps pour le configurer.

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

              • [^] # Re: Oh my fish

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

                Ah bah en cherchant la doc sur les raccourcis, tous ceux que tu cite semblent être présent:
                http://fishshell.com/docs/current/index.html#editor

                Et tu peux changer les raccourcis avec la commande bind.

  • # ça m'énerve...

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

    J'ai lu rapidement la doc, mais sur ma centOS 6.5 en bash version 4.1.2, une fois que j'ai sourcé liquidprompt, mon prompt ressemble à ça (avec les guillemets "" pas beaux au début) :
    ""[rictus:~] $

    c'est quoi que j'ai manqué ? :(

Suivre le flux des commentaires

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