Michaël a écrit 2935 commentaires

Pour utiliser différents outils de workflow (ou affilié)

Qu'est-ce que tu utilises dont tu es content? J'ai commencé à implémenter une bibliothèque en OCaml pour faire cela et j'aimerais bien regarder l'API d'autres solutions pour m'en inspirer.

C'est toi que ça regarde.

Heu, je ne comprends pas trop le sens de cette discussion? J'explique pourquoi je n'ai pas de problème à traiter les données tabulaires avec le shell c'est tout simplement parceque je ne le fais pas – et ce, sciemment. C'est grave d'échanger des points de vue et des expériences?

Pour utiliser différents outils de workflow (ou affilié) le shell est assez mauvais pour ça …

Effectivement, pour les tâches complexes, je trouve le shell excellent pour écrire des prototypes – plutôt fragiles et lents, mais rapides à écrire.

Ça se manipule bien avec des sed/grep/awk/perl, mais en shell c'est une infamie

Ma règle d'or de la programmation shell est de traiter aussi peu de données que possible avec le shell que je considère plutôt comme un outil de description des workflows qui transfère des données d'/un processus à l'autre, si possible sans regarder ce qu'il y a dedans.

quand tu veut t'en servir comme d'une configuration, l'utilisation sous forme tabulaire n'est pas pratique (tu dois de toute manière déserialiser ton fichier).

Ça dépend un peu des cas d'utilisation: s'il s'agit de lire une batterie de paramètres, je suis complètement d'accord avec toi, cependant si on a une collection de valeurs a priori inconnue (du style git qui a des paramètres pour chaque branche, mais ne connaît pas a priori le nom des branches), alors une donnée tabulaire peut-être pertinente.

On peut aussi traduire la donnée tabulaire en fichier contenant des affectations puis sourcer ce fichier, au lieu de faire ça “ligne à ligne” ce qui est forcément très bavard (code) et très lent.

le temps et l'expérience m'ont donné une préférence pour les softs qui font qu'une chose, parce que je suis pas assez intelligent pour en faire plus

C'est en soi une assez bonne raison, il y a d'autres raisons mentionnées ici:

http://marmaro.de/docs/studium/unix-phil/unix-phil.pdf

En gros, le point important est que l'orthogonalité des composants favorise leur réutilisabilité.

Si tu ne connais pas encore le texte de Thomas Scoville “UNIX as literature” ta prose me laisse penser que tu l'apprécieras beaucoup!

http://theody.net/elements.html

donc, tu es l'auteur d'anvil…

Il y a environ 216 projets libres qui s'appellent anvil je ne suis probablement pas l'auteur de clui auquel tu penses! :)

Je ne sais pas si c'est malheureux ou pas, mais je suis un développeur C++

Le shell est un paradigme de programmation à part entière, l'erreur de base à ne pas commettre est de vouloir ranger les données dans la mémoire du shell alors que les données vivent en dehors du shell. Le shell est une sorte de méta-langage qui décrit un workflow.

Voilà un article de mon blog qui parle de cela (en anglais): http://unix-workstation.blogspot.de/2015/04/delegating-complex-treatments-to.html

Pour apprendre le shell le plus facile est de lire des programmes écrits par d'autres. De toute évidence la plupart des scripts sont hyper mal écrits mais quand on regarde aux bons endroits – du genre les scripts d'init de FreeBSD et ce genre de choses – on améliore ses chances de trouver de la littérature potable.

Pour le côté “stratégique” de la programmation en shell j'aime beaucoup UNIX Shell Programming de Lowell Jay Arthur, 4 ème édition, 2€ maxi d'occasion.

J'écris ce projet essentiellement en shell https://github.com/michipili/anvil

Ton format csv est une plaie à utiliser en shell.

On est régulièrement en désaccord là-dessus. Pour moi les données tabulaires sont à la base de la programmation en shell et je n'écris quasiment que des filtres qui lisent et écrivent des données tabulaires – et font parfois quelques traitement aussi! – bien-sûr cela demande de ne pas écrire de caractères NUL, de CR ou PIPE dans les champs, mais dans mon cas ce n'est pas une limitation.

Je suis donc très content avec les données tabulaires. Quels sont les problèmes qu'elles te posent?

C'est du sh tout ce qu'il y a de plus normal. J'utilise sh tout le temps parceque je pousse les shells dans leurs retranchements, ça segfault, et donc rester dans le sh permet de passer facilement d'un shell à l'autre en cas de besoin.

Je trouve le UNIX Grymoire très utile, à la fois simple et clair – mais il ne parle pas du tout d'ingénierie et d'organisation des programmes.

2ème conseil: force un sous dossier de la racine,

Je préfère utiliser le modificateur :? qui déclenche une erreur si la variable qu'il modifie n'est pas définie:

find "/${backup_dir:?}" -type f -prune -mtime +7 -exec rm -f '{}' \;


Sincèrement, je n'ai pas l'envie d'apprendre l'Anglais.

Pourtant tu fais déjà des anglicismes en mettant des majuscules rigolotes dans tes phrases. Remarque perfidement tatillonne mise à part, apprendre des langues étrangères permet de s'ouvrir à plein de choses — et pas seulement aux documentations techniques sur l'analyse forensique. En plus quand on connaît bien un sujet technique, c'est très facile d'apprendre l'anglais “par imprégnation” — j'ai essentiellement appris l'anglais en lisant usenet puis plus tard j'ai appris à parler.

Ce n'est pas du bash pur car tu appelles une ou deux fois sed par ligne lue, et cela ne fait pas du tout la même chose car tu ne produis pas de donnée tabulaire. Remarque, je ne programme pas en bash car c'est tout plein de bugs — dès que le job control devient compliqué, cela fait des segfaults.

C'est probablement does not exist ou doesn't exist. Mais au passage exist ça fait un peu vocabulaire mathématique et on utilise souvent plutôt no such … ou … not found — par exemple chez moi:

% ls /nonexistant
ls: /nonexistant: No such file or directory

Quitte à lancer une instance de sed autant la laisser faire tout le travail, non?

Mais ça ne fait pas du tout la même chose que le script sed puisque cela définit tout un tas de variables avec les valeurs assignées, du coup à moins de faire de l'introspection plutôt hasardeuse, tu ne peux pas itérer sur les valeurs définies mais seulement lire les valeurs que tu attends.

Avec le script sed on peut transformer un fichier INI comme la config de git en donnée tabulaire, du type

core|repositoryformatversion|0
core|filemode|true
core|bare|false
core|logallrefupdates|true
remote "origin"|url|git@github.com:michipili/anvil.git
remote "origin"|fetch|+refs/heads/*:refs/remotes/origin/*
branch "master"|remote|origin
branch "master"|merge|refs/heads/master

ce qui permet de sélectionner avec awk toutes les url de remotes par exemple.

Dans le cadre de scripting système dans un environnement pro ça me semble en effet une mauvaise idée de construire de trop gros script en pur shell.

Contrairement à plein de croyances, ce n'est pas si difficile d'écrire des programmes complexes, maintenables et relativement gros avec le shell. La clef c'est de ne pas utiliser le shell n'importe comment. En gros il faut éviter le plus possible de maintenir des données complexes dans le shell lui-même, le shell servant juste à lancer des programmes — plus spécifiquement, des filtres — qui vont effectuer les traitements. En général on part de fonctions “prototypes” et de “mockings” pour écrire très rapidement un prototype. Ensuite on étend le prototype et on peut remplacer les traitements trop complexes par des programmes autonomes. Évidemment, il s'agit de faire du bon gros traitement de données pas du tout interactif, pour les programmes interactifs, cette approche ne va pas du tout!

En fait, je parlais d'interface utilisateur, claire et légère, pas d'API.

J'avais bien compris, je parlais de l'API claire juste pour nuancer l'aspect non-libre du projet: on peut récupérer facilement toutes ses données, et ce, dans un format potable.

Je lui préfère redmine. Du moins c'était le cas la dernière fois que j'ai comparé les deux.

Je n'ai jamais utilisé redmine, qu'est-ce que tu lui trouves de mieux que trac? Ce que j'apprécie beaucoup dans trac c'est le wiki, qui est très très bien intégré avec le système de tickets, et le fait que c'est relativement facile d'écrire des plugins, choses que j'ai déjà faite bien que je n'utilise python que très occasionnellement aujourd'hui.

Je rappelle que le but est d'avoir un jeu sympa sous Linux, donc avec une IA acceptable. Le risque est alors d'avoir N IA pas terribles. Imagine un Battle For Wesnoth avec cette liberté …

D'après ce que j'ai compris, ton problème est pour l'instant que l'IA n'est pas terrible. Si tu cherches des contributions externes ton intérêt est d'avoir le moins de barrières possibles. Si une IA marche bien, rien n'interdit de la recoder en JS ou ce que tu veux quand il s'agira de la pérenniser.

C'est exactement ce que je veux suggérer aussi.

Au lieu d'imposer un langage (JS, que je parle bien) c'est plus flexible de parler à ton IA via un Unix pipe. Tu délègues donc la décision à un programme externe.

On peut imaginer le protocole suivant:

1. Le jeu démarre le programme super_ia
2. Le jeu décrit la partie (nombre de joueurs, position) la donne à super_ia
3. super_ia répond qu'il est prêt
4. Le jeu lance le premier tour d'enchères et écrit les résultats sur srdin de super_ia
5. super ia répond avec son enchère … etc.

Le plus simple est d'utiliser un protocole textuel (tu peux tester directement à la console) avec une convention simple pour séparer les commandes (le plus simple est le ligne à ligne, vu que tu n'as pas beaucoup de données à transférer, ça me semble adéquat). Tu peux t'inspirer des protocoles semblables comme FTP ou SMTP par exemple, en essayant d'être plus simple que eux! :)

Certes, mais Savannah propose , via une interface claire et legere, des choses telles qu'un site web ou hébergement de binaires. Github est très bien pour des devs, mais pour l utilisateur final, j'ean doute fort.

C'est aussi le cas de GitHub!

Les logiciels de type “forge” sont très touffus et d'une part difficile à déployer et d'autre part offrent des tas de fonctions souvent pas employées: lorsque je visite un projet sur une forge, je passe souvent mon temps à explorer des patrons de contenu “ce projet n'a publié aucune documentation”, “ce projet n'a publié aucun X” etc. plus que du contenu lui-même. Pour moi c'est difficile d'associer cette expérience à la clarté.

On peut regretter que GitHub ne soit pas libre (à part certains composants) mais on peut se réjouir de voir qu'ils offrent une API claire pour accéder à la base de données des tickets de suivi d'un projet, et donc qu'ils n'enferment pas leurs utilisateurs. Parmi les projets libres, je trouve trac mille fois plus clair et léger – et plus utile – que les forges classiques, c'est dommage qu'il soit si difficile (ou impossible) de trouver un hébergement gratuit pour de projet sous trac.

Ça y est, j'ai détruit mon compte SourceForge!

C'est une vraie question.

Aucun, c'est une vraie réponse.

On peut imaginer un scénario plus évolué où la clef secrète est l'une d'une clef USB qui est retirée après le boot, ce qui protégerait les données lorsque la machine est volée après avoir été mise hors tension.

heu, c'est pas contradictoire "non informaticien" et "markdown" dans la meme phrase ?

Pourquoi le serait-ce? Il y a plein de non-informaticiens qui apprennent TeX ou LaTeX, et markdown est beaucoup plus facile. Ce qui compte plus qu'une “affinité technique”, c'est l'utilité perçue.

Je suppose que comme en français, en anglais et en allemand, l'ordre des mots introduit une nuance – qui dans certain cas peut marquer une assez grosse différence de sens ou d'intention.

(Précisons pour être particulièrement clair que bien évidemment je suis totalement contre ces agissements)

Ah zut, j'étais en train de réchauffer une petite réflexion du genre “LinuxFR est un repère de petit jeunes cons sans aucune valeur morale!” et puis tu m'as coupé l'herbe sous le pied! :D