nojhan a écrit 634 commentaires

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

Comme dit dans la dépêche, Plumbum fait la même chose que chut, mais par dessus le module sh, qui utilise un hack très élégant pour l'import des commandes shell sous la forme de fonction. L'API est uber-cool, tu peux appeler les commandes sans même voir que c'est de l'appel système :

>>> from plumbum.cmd import cat, head
>>> ((cat < "setup.py") | head["-n", 4])()

Tu devrais regarder leur code pour simplifier l'appel de tes commandes dans chut ;-)

Techniquement — dans ce cas précis — c'est à la fois un mélange des deux et un peu entre les deux.

Si j'avais voulu pinailler, j'aurais sans doute utilisé computational intelligence (difficilement traduisible en français ?).

Mais comme « intelligence artificielle » me semble à la fois plus connu et plus cool, je l'utilise pour mes offres de stage, dans une tentative bassement publicitaire d'appâter le chaland.

Ça ressemble à un vieux bug. Normalement, il ne devrait pas y avoir deux commandes dans cette variable, mais une seule… à moins que tu aies bidouillé des trucs à la main.

Normalement ça marche déjà sous mac… enfin j'ai rien pour tester, mais il y a un type qui l'utilise, a priori.

Il y a plus classe que d'afficher l'horloge. Il semblerait qu'en ajoutant des hooks, on peut directement mesurer le temps pris par la commande exécutée : http://www.twistedmatrix.com/users/glyph/preexec.bash.txt

C'est plus intéressant, car, a priori, on peut alors n'afficher le temps pris par la dernière commande que s'il dépasse un certain seuil. J'envisage de mettre ça dans le liquid prompt, mais faut voir si ça ne deviens pas trop ingérable niveau temps d'exécution du prompt, justement.

Après mesures il semblerait que les regexp ne soient pas l'élément discriminant :

$ ./mtime.sh 10000 < load_commands | sort
6.05    uptime | awk '{print substr($10,0,length($10))}'
6.15    uptime | sed  "s/^.*average: \([0-9]\.[0-9][0-9]\),.*$/\1/"
6.17    uptime | awk '{ sub(",","",$10); print $10}'
6.23    uptime | awk 'BEGIN { FS = " |," } {print $17}'
8.02    uptime | awk '{print $10}'| sed -e 's/,//'

Mais tu gagnes quand même :-)

Je ne connais pas Zsh, mais le diff ne semble pas si différent qu'en bash… y aurait-il moyen de regrouper les deux dans le même script avec une détection du type de shell ?

Le bug sur la batterie est corrigé.

J'ai rajouté des variables en tête de fichier pour permettre de configurer les seuils d'affichage pour la batterie et la charge.

Perso, j'aime bien garder un seuil élevé car je m'habitue beaucoup trop aux widgets sur X, ils sont toujours affichés, dans un coin que je regarde rarement, avec toujours la même apparence… alors que l'apparition d'un truc sur le prompt me saute aux yeux !

On peut assez facilement changer les couleurs… ceci étant dit, le gris empêche d'utiliser beaucoup des couleurs ANSI… peut-être en ajoutant un fond noir partout ?

Je ne sais pas si ça vaut le coup d'avoir une config à part pour gérer ça.

La dernière version fixe ce bug en ne gardant que logname.

Peut-être en bidouillant quelque chose avec colout : https://github.com/nojhan/colout

Il y en a plusieurs, mais pour moi, le plus prometteur est sans conteste TermKit : http://acko.net/blog/on-termkit/

J'en prend bonne note. C'est con, d'ailleurs, comme erreur, parce que les stagiaires qui passent par chez nous sont toujours enchantés d'être passé et d'avoir été bien encadré (enfin je crois).

Je veux bien publier, mais il faudrait savoir où… on a fait les mailing-lists du domaine, quelques écoles… d'autres idées ?

Clairement. Le coup du type qui aligne des options intéressantes à ses diplômes, sur son CV, mais qui n'a rien à montrer et qui n'est pas capable d'expliquer en quoi son code est cool… c'est déprimant.

Mettez vos projets sur vos CV et expliquez ce que vous avez fait de cool dans vos lettres e-mails de motivation et épargnez-moi les banalités du genre « je souhaite valoriser mes compétences en systèmes d'information »… peut-être que ça m'évitera des faux négatifs :-)