Apparemment tu partages ma tendance à utiliser l'outil le plus simple qui te permet de faire le travail (car tu préfères apprendre AWK que PERL). Comme bash est un gros shell bien gras, tu peux réfléchir à apprendre sh plutôt que bash. L'avantage est que tu programmeras de façon un peu plus portable — ce qui peut toujours s'avérer utile. Pour la programmation, le gros plus de bash, c'est les tableaux… quelque part j'ai envie de dire que le shell ne sert pas à programmer, mais à décrire un workflow, et que le besoin de tableau témoigne d'un problème qui ne doit pas être résolu dans le shell.
En gros l'idée est que si tu utilises beaucoup ton tableau, il vaut peut-être mieux écrire un petit outle pour résoudre ton problème. Sinon, tu peux très bien le coller dans un fichier, voire dans un dossier.
Ce livre est souvent controversé, mais je te le recommande tout de même: Unix shell programming de Lowell Jay Arthur (2nd édition, c'est important car souvent dans ce genre de livre, les éditions varient substantiellement). Ce livre est très imprégné de la philosophie Unix et si tu le comprends bien tu sais bien à quoi sert le shell. Le point clef est que le shell sert à décrire un workflow et que le programme que tu coordonnes (avec des pipes) doivent travailler sur une représentation commune des données, la plus simple possible. (XML et JSON sont beaucoup trop complexes!)
Exemples:
— onsgmls (James Clark) permet de passer d'un SGML à une version validée et facile à traiter en shell (chaque élément, attribut, etc. apparaît sur sa propre ligne).
— noweb (Norman Ramsey) utilise un format trivial pour pouvoir piper ses données vers un filtre unix donné par l'utilisateur. (Ce qui au passage te fait une source d'exemples de scripts awk.)
Le point clef de la programmation shell est donc la création de programmes élémentaires qui travaillent sur une représentation commune des données, si possible assez simple pour éventuellement être travaillée avec sed, awk, … (cela évite d'avoir à coder des analogue de awk et sed pour la représentation en question).
Les défauts de la plupart des gens:
— sous-utilisation du système de fichiers (le plus simple pour implémenter une table associative est d'utiliser le système de fichiers, Lowell Jay Arthur explique ça très bien).
— sous-utilisation des pipes nommés pour les IPC.
— utilisation de echo lorqu'il faut utiliser printf (echo sert à afficher un message pour l'utilisateur, tout le reste doitr être géré par printf).
Quelques conseils pour se simplifier la vie:
— pour toutes tes interpolations de type backquote un tant soit peu compliquée, écris une fonction auxiliaire: tu éviteras toutes sortes de migraines liées aux échappements et aux quotes!
— cale toutes tes boucles while read dans une fonction à part, cela te simplifiera aussi la vie!
Je me demandais si à part awk et sed, il y avait d'autres utilitaires necéssaire qui sont satellites à bash (dans le meme ordre d'idées que le coreutils)
En gros les thématiques de bases sont:
fichiers: date (pour les noms horodatés), mv, cp, rm, tar, find, xargs, mktemp ou sa variante qui marche.
base de données: join, paste, etc. (pour préparer ton input à awk! et trop souvent méconnus)
filtres: sort, sed, awk, cut, head, tail, grep.
portabilité: command.
make
Ensuite viennent les outils correspondant au domaine de ton problème:
unix: stat, ps, id, /etc/passwd, etc.
…
Bon courage et amuse-toi bien!
(PS la seconde édition du livre de Lowell Jay Arthur est complètement obsolète — je crois qu'elle parle de System V si bien qu'aucun des exemples du livre ne marche directement, cela fait travailler!)
[^] # Re: Dur
Posté par Michaël (site web personnel) . En réponse au message Utiliser awk pour calculer la somme d'une ligne jusqu'à une autre.. Évalué à 3. Dernière modification le 17 août 2012 à 22:11.
Apparemment tu partages ma tendance à utiliser l'outil le plus simple qui te permet de faire le travail (car tu préfères apprendre AWK que PERL). Comme bash est un gros shell bien gras, tu peux réfléchir à apprendre sh plutôt que bash. L'avantage est que tu programmeras de façon un peu plus portable — ce qui peut toujours s'avérer utile. Pour la programmation, le gros plus de bash, c'est les tableaux… quelque part j'ai envie de dire que le shell ne sert pas à programmer, mais à décrire un workflow, et que le besoin de tableau témoigne d'un problème qui ne doit pas être résolu dans le shell.
En gros l'idée est que si tu utilises beaucoup ton tableau, il vaut peut-être mieux écrire un petit outle pour résoudre ton problème. Sinon, tu peux très bien le coller dans un fichier, voire dans un dossier.
Ce livre est souvent controversé, mais je te le recommande tout de même: Unix shell programming de Lowell Jay Arthur (2nd édition, c'est important car souvent dans ce genre de livre, les éditions varient substantiellement). Ce livre est très imprégné de la philosophie Unix et si tu le comprends bien tu sais bien à quoi sert le shell. Le point clef est que le shell sert à décrire un workflow et que le programme que tu coordonnes (avec des pipes) doivent travailler sur une représentation commune des données, la plus simple possible. (XML et JSON sont beaucoup trop complexes!)
Exemples:
— onsgmls (James Clark) permet de passer d'un SGML à une version validée et facile à traiter en shell (chaque élément, attribut, etc. apparaît sur sa propre ligne).
— noweb (Norman Ramsey) utilise un format trivial pour pouvoir piper ses données vers un filtre unix donné par l'utilisateur. (Ce qui au passage te fait une source d'exemples de scripts awk.)
Le point clef de la programmation shell est donc la création de programmes élémentaires qui travaillent sur une représentation commune des données, si possible assez simple pour éventuellement être travaillée avec sed, awk, … (cela évite d'avoir à coder des analogue de awk et sed pour la représentation en question).
Les défauts de la plupart des gens:
— sous-utilisation du système de fichiers (le plus simple pour implémenter une table associative est d'utiliser le système de fichiers, Lowell Jay Arthur explique ça très bien).
— sous-utilisation des pipes nommés pour les IPC.
— utilisation de echo lorqu'il faut utiliser printf (echo sert à afficher un message pour l'utilisateur, tout le reste doitr être géré par printf).
Quelques conseils pour se simplifier la vie:
— pour toutes tes interpolations de type backquote un tant soit peu compliquée, écris une fonction auxiliaire: tu éviteras toutes sortes de migraines liées aux échappements et aux quotes!
— cale toutes tes boucles
while readdans une fonction à part, cela te simplifiera aussi la vie!En gros les thématiques de bases sont:
fichiers: date (pour les noms horodatés), mv, cp, rm, tar, find, xargs, mktemp ou sa variante qui marche.
base de données: join, paste, etc. (pour préparer ton input à awk! et trop souvent méconnus)
filtres: sort, sed, awk, cut, head, tail, grep.
portabilité: command.
make
Ensuite viennent les outils correspondant au domaine de ton problème:
unix: stat, ps, id, /etc/passwd, etc.
…
Bon courage et amuse-toi bien!
(PS la seconde édition du livre de Lowell Jay Arthur est complètement obsolète — je crois qu'elle parle de System V si bien qu'aucun des exemples du livre ne marche directement, cela fait travailler!)