LiquidPrompt est un prompt clefs-en-main pour bash ou zsh, dont l'idée générale est d'afficher élégamment des informations utiles uniquement quand le contexte le demande.
De nombreuses nouveauté sont disponibles depuis la dernière linuxfrisation, notamment :
- la gestion de zsh en plus de bash ;
- des commandes pour désactiver temporairement le prompt (et revenir à l'ancien ou carrément tout désactiver) ;
- de quoi configurer facilement le prompt dans des fichiers à soi (couleurs, thèmes, options) ;
- la désactivation optionnelle de chaque fonctionnalité du prompt (même à chaud) ;
- une couleur indiquant si le forwarding X est actif ;
- gestion du chroot sous Debian et du virtualenv sous Python ;
- la réplication du prompt dans le titre de la fenêtre ;
- la gestion de Fossil (le gestionnaire de version) ;
- la possibilité de masquer l'utilisateur, si c'est celui qui est loggué ;
- l'utilisation du builtin DIRTRIM, sous bash, s'il est installé ;
- un fichier
.bashrcà utiliser pour l'installation ; - plein (mais alors plein) de bugs en moins et de vitesse en plus !
Aller plus loin
- Code sur github (589 clics)
- Capture d'écran (2686 clics)
- Plus d'infos sur la dépêche précédente (234 clics)
- Documentation (257 clics)
# Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Complémentarité avec byobu
Posté par nojhan (site web personnel, Mastodon) . Évalué à 1.
Je me suis moi-même longtemps reposé sur des widgets de notifications, mais ça n'était pas pratique en connexion distante. Puis sur des barres de titres dans le terminal, mais comme c'était toujours au même endroit, ça ne sautait rapidement plus aux yeux.
Finalement, ce qu'il me fallait c'est mettre l'info là ou je regardais tout le temps (le prompt, et pas tout en bas de l'écran) et uniquement quand c'est nécessaire (de manière à ne pas l'ignorer par habitude).
Le seul bémol du prompt étant qu'il n'est pas mis à jour en temps réel. Mais je tape suffisamment de commandes pour que ça ne soit qu'un problème mineur, et j'ai pris le réflexe d'appuyer sur entrée assez facilement pour mettre à jour.
Un avantage que je n'avais pas prévu, c'est aussi qu'un prompt bien fait permet de repérer facilement les différentes parties des affichages à l'écran.
# Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Conflit propagé
Posté par nojhan (site web personnel, Mastodon) . Évalué à 1.
Corrigé, merci.
# Question bête ...
Posté par sifu . Évalué à 1. Dernière modification le 17 janvier 2013 à 11:42.
Je peux pas essayer cela actuellement.
Est ce que dans les informations fournies pour Git on dispose des éléments suivants: ?
- affichage des modifications non "commitées"
- affichage des informations sur les push et pull (avance et retard)
J'utilise personnellement les informations de git-completion.bash (__git_ps1).
Merci.
[^] # Re: Question bête ...
Posté par nojhan (site web personnel, Mastodon) . Évalué à 1.
Le prompt affiche le nombres de lignes en plus/moins des modifications non commitées en rouge, le nombre de commits non pushés en jaune.
Récupérer à chaque affichage le retard sur pull serait bien trop lent pour le prompt. Mais on peut peut-être envisager un job en arrière plan et un cache…
[^] # Re: Question bête ...
Posté par sifu . Évalué à 1.
Pourtant, il me semble l'avoir vu fonctionné sans ralentissement (cf. http://gitfr.net/blog/2010/11/06/ameliorer-sa-productivite-avec-un-beau-shell/).
Il faudrait que je regarde cela sur ma machine ce soir.
[^] # Re: Question bête ...
Posté par nojhan (site web personnel, Mastodon) . Évalué à 1.
Il faut passer par le réseau pour voir l'écart avec un dépôt distant… je ne suis pas sûr que ça soit très rapide… et se reposer sur un fetch de l'utilisateur n'est pas très ergonomique. Le module git_ps1 est rapide, parce qu'il n'est pas en bash, je suppose ? Peut-être qu'on pourrait parser sa sortie au lieu de passer par des appels systèmes ?
[^] # Re: Question bête ...
Posté par Renaud Casenave-Péré . Évalué à 1.
Sauf si tu as l'habitude de faire des git fetch à la main régulièrement.
# Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Licence
Posté par nojhan (site web personnel, Mastodon) . Évalué à 4.
On peut utiliser un prompt en se connectant sur un serveur, sans avoir à le télécharger. D’où l'AGPL.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
# PROMPT_COMMAND
Posté par ckyl . Évalué à 2.
Ca vaudrait peut être le coup de documenter qu'il ne faut pas écraser le PROMPT_COMMAND après avoir sourcé liquidprompt. C'est très con, mais ca ma demandé 10 minutes pour me souvenir que j'avais un moche
PROMPT_COMMAND='history -a'qui traînait quelque part.[^] # Re: PROMPT_COMMAND
Posté par nojhan (site web personnel, Mastodon) . Évalué à 2.
Corrigé, merci.
[^] # Re: PROMPT_COMMAND
Posté par ckyl . Évalué à 2.
Ca t'intéresse que je regarde pour ajouter le support de Bazaar ?
[^] # Re: PROMPT_COMMAND
Posté par ord . Évalué à 1.
moi, ca m'interresse. Si tu le fait pas rapidement, je le ferai. Ca l 'aire que il y a que 2 functions a rajouter.
[^] # Re: PROMPT_COMMAND
Posté par ckyl . Évalué à 2.
Affirmatif. J'ai fait un proto rapidement, le support modifié/non modifié est trivial. Avoir le même niveau de support que git demande un peu plus de travail par contre (notamment les commits locaux à pusher et le numstat). Il serait peut être bon d'avoir une nouvelle couleur pour les merges non commités aussi.
Après les perfs de Bazaar étant toujours aussi désastreuses ca plombe pas mal l'interactivité du shell. Faut voir si c'est viable car un simple bzr nick et bzr diff rendre le shell inutilisable…
Je pousserais ce que j'ai fait ce soir ou lundi.
[^] # Re: PROMPT_COMMAND
Posté par ord . Évalué à 1.
juste pour info, jæavais un script qui faisait quelquechose de similaire et la commande utilise etait:
time bzr version-info --check-clean --custom --template='{revno} {clean}'
31 0
real 0m0.088s
user 0m0.080s
sys 0m0.004s
[olivier@utgaard:~/bin] $ bzr nick
bin
[olivier@utgaard:~/bin] $ time bzr nick
bin
real 0m0.085s
user 0m0.076s
sys 0m0.008s
[olivier@utgaard:~/bin] $
et c 'est vrais que compare a git ca parait lourd
time git symbolic-ref HEAD
refs/heads/master
real 0m0.001s
user 0m0.000s
sys 0m0.000s
time git rev-parse --git-dir
.git
real 0m0.002s
user 0m0.000s
sys 0m0.000s
Tu peux au moins essayer de faire tout en une commande avec --template puisque c est le temps de demarage qui est long
[^] # Re: PROMPT_COMMAND
Posté par ckyl . Évalué à 2.
Y'a un pull request en attente. Si tu as une idée de comment détecter les commits qui n'ont pas été pushés sans rajouter de coût à l'exécution n'hésite pas.
Le support de bzr se sent quand même dans les perfs. On peut améliorer le truc car le design actuel de _lp_set_prompt force à lancer deux fois bazaar alors qu'une suffirait. Je suis pas sur d'avoir le temps de m'y pencher si tu as du temps à perdre ;)
# blacklist de rep
Posté par Guillaume Denry (site web personnel) . Évalué à 3.
Je suis tombé sur un cas un peu tricky.
Depuis mon linux, je mount en ssh (sshfs) un répertoire sur une machine FreeBSD.
Lorsque je me rend dans mon point de montage, comme j'ai activé $LP_ENABLE_SVN et que ce répertoire sur la machine FreeBSD est un dépôt, liquid lance les commandes afférentes mais ça part en timeout (pas le même fichier de config, pas la même version de svn, pas les mêmes identifiants, etc etc) sans me rendre le prompt (ce qui me semble normal).
A priori, ça pourrait être sympa de pouvoir définir des blacklist/whitelist pour certaines options.
Mais ça serait un raffinement.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.