Ça devait être aux alentours de 2005, sur une ML quelconque, je ne retrouve même plus l'image dans mes sauvegardes :-(
J'ai plus qu'à m'y remettre :-)

Ça devait être aux alentours de 2005, sur une ML quelconque, je ne retrouve même plus l'image dans mes sauvegardes :-(
J'ai plus qu'à m'y remettre :-)

Moi aussi, même si je suis techniquement déjà utilisé. Ceci étant dit, j'ai déjà proposé un logo, mais je n'ai eu aucun retour…
Et d'ailleurs, il n'y pas de mailing-list graphisme d'indiquée dans la dépêche ? :-)

Une fonction ou un alias, par exemple j'utilise ça pour colorer une sortie de build cmake/g++ :
function cm()
{
$@ 2>&1 | colout -t cmake | colout -t g++
}
Ça s'utilise simplement :
cm ./build_script

Il y a peut-être moyen de refactoriser un peu colout pour qu'il puisse servir de module pour faire ce genre de truc aussi…

L'exemple le plus frappant est la lecture d'une sortie très verbeuse, comme par exemple la sortie de gcc.
Tu ne veux pas filtrer avec grep parce que tu peux avoir besoin de tout lire. Par contre il est pratique de pouvoir repérer très rapidement les passages qui t'intéressent (les erreurs, par exemple). Les couleurs sont un moyen très efficace de faire ça.
C'est pour ça que j'ai commencé à faire colout, mais je me suis assez vite rendu compte que le problème se posait aussi pour plein d'autres choses (diff, logs) et même dans des cas où j'utilisais grep habituellement (grep de code source, par exemple).
On peut se dépatouiller avec grep ou d'autres commandes dédiées (git coloré, colordiff, ccze, etc.) dans la plupart de ces cas mais je me suis vite rendu compte qu'il était très pratique d'avoir une seule commande bien pensée pour remplacer plein de façon disparates de faire moins bien.

C'est ce que fait l'option -t avec les fichiers de thème.
Un thème est une fonction qui renvoie une liste de la forme :
[
["regexp1", "couleur1,couleur1", "style"],
["regexp2"] # couleur et style par défaut
]
Voir les fichiers colout_*.py pour des exemples.

Je ne suis pas sûr d'avoir bien compris à quoi ça servait, même si ça à l'air cool…
Est-ce que ça pourrait m'aider à faire une translitération "inverse" : d'une représentation multi-caractères latins vers de l'unicode ? (notamment vers du cunéiforme ?)

Dernier commit voilà 4 mois… pour moi ça n'est pas assez long pour déclarer une mort clinique…

J'aime bien l'idée, même si ça doit ramer à mort… tu nous fais une demande de fonctionnalité ?
https://github.com/nojhan/liquidprompt/issues/new :-)

TermKit : http://acko.net/blog/on-termkit/

Ça n'est clairement pas fait pour un RPi… ceci étant dit, un prompt de base n'est pas non plus fait pour une bête de course :-)
Tu peux réduire de beaucoup le temps d'exécution en jouant avec les variables LP_ENABLE_* ou en virant des fonctionnalités dans ton propre LP_PS1 (cf. la doc).

un prompt sur deux lignes…
comme ça je peux avoir le chemin en entier sur la première ligne.
Est-ce possible comme évolution/option ?
Pas pour le thème par défaut.
Mais tu peux tout à fait configurer le liquid prompt différemment, sans toucher au code.
Le plus simple est sans doute d'utiliser "]\n" pour LP_MARK_BRACKET_CLOSE, mais tu peux régler le prompt encore plus finement en utilisant ton propre LP_PS1. La doc explique tout ça avec des exemples, voir aussi les fichiers liquid.ps1 et liquid.theme.

Corrigé, merci.

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 ?

WTFOO : What The Fuck Object Oriented. C'est une vanne sur la lourdeur syntaxique du C++.
Pour des exemples d'opérateur $, voir le langage fonctionnel Haskell.
Je me garderais bien de donner un avis tranché sur l'élégance, quant à moi :-)

On peut utiliser un prompt en se connectant sur un serveur, sans avoir à le télécharger. D’où l'AGPL.

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…

Avec Plumbum, je ne sais pas trop, mais avec chut ou pyxshell, c'est trivial, il suffit d'utiliser map avec une fonction (lambda, par exemple).
Ça devrait être un truc du genre :
ls("-l") | map( lambda x : rm(x) )

Corrigé, merci.

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.

Et si on fusionnait les deux ? J'aimerais assez avoir le choix de l'origine des commandes utilisées (système ou python).
Par exemple, on aurait le choix d'utiliser from chut.sys import * (commandes dispo sur le système) ou from chut.cmd import * (réimplémentations pure python).

C'est encore la doc de calabash, je n'ai pas encore pris le temps de soumettre ça sur pypi.
C'est un fork plus ou moins compatible (calabash n'est pas en python3, mais sinon c'est juste une extension). Les explications sur le changement de nom sont dans mon premier commit.
En gros, calabash était déjà très googlé et pas très vendeur.

Je ne sais pas si vous vous en rendez compte, mais c'est un vieux troll, qui a eu ses beaux jours à l'arrivée de la POO.
De fait, les différentes syntaxes sont équivalentes, mais il y en a d'autres, aussi… quelques exemples :
data | op1 | op2(arg) | op3 > var # style shell infixé
var = Pipe(data).op1().op2(arg).op3() # style POO
var << Pipe(data)->op1()->op2(arg)->op3() # style WTFOO
var := op3(op2(op1(data),arg)) # style fonctionnel préfixé
var <- op3 $ op2 $ arg op1 $ data # style fonctionnel infixé
var = (data op1) arg op2 op3 # style fonctionnel postfixé
etc. ?
Personnellement, j'ai l'habitude de traiter les flux en shell, et j'aime bien que le traitement se lise de gauche à droite, sans fioritures. D'ailleurs, je me garderais bien de décréter que tel ou tel style est le plus pythonique dans ce cas précis. le fait est que l'infixé avec pipe me parait à la fois plus concis, plus intuitive et est plus simple à implémenter. CQFD.

Du coup j'ai rajouté une commande sleep :-)

Les commandes sont implémentées comme des générateurs (cf. la doc sur yield), donc la chaîne complète forme une fonction, qui s'exécute en entier tant que l'itérable passé a qqchose à envoyer (et qu'il n'y a que des générateurs dans la séquence). Donc, sur des traitements long, tu verras les lignes s'afficher au fur et à mesure.
Dans l'exemple suivant, la fonction sleep ne fait qu'attendre avant de passer le prochain item, et les chiffres s'affichent bien au fur et à mesure :
>>> import time
>>> from pyxshell.common import *
>>> @pipe
def sleep(stdin,t):
for i in stdin:
...: time.sleep(t)
...: yield i
...:
>>> for i in ( range(3) | sleep(1) ):
print(i)
....:
0
1
2