Je n'ai personnellement jamais mis en défaut gred, sed, cut ou awk (et pourtant j'aimerais bien pour avoir l'occasion de jouer avec perl).
Mais quand on commence à vouloir croiser les données issues de plusieurs fichiers (ou sorties de processus) différents, les outils de base d’Unix avouent leurs limites : le principe du pipe, ça va bien tant qu’on n’a qu’une source... L’avantage de Perl par rapport à des outils Unix « pipés », c’est qu’on reste dans son script, on ne perd pas ses variables à chaque étape.
Bon, awk tient quand même la route plus longtemps que les autres outils de base.
Malgré cela, je ne l’utilise quasiment plus, parce que tout ce qu’on peut faire en awk, on peut le faire en Perl en à peine plus long, et même quasiment à l’identique si on veut*, mais que si jamais on veut faire d’autres trucs ensuite, avec Perl, on a toute la puissance du langage, de sa bibliothèque standard et de son dépôt (dont Time::HiRes, utilisé par TapTempo.pl)...
* Par exemple, on peut transcrire le script awk de ce journal simplement en :
Je vous invite à faire une comparaison avec la version awk du journal à l’aide de meld ou tkdiff ; ce n’est pas un hasard que ce soit si similaire : les premières versions de Perl visaient justement à remplacer le shell et les outils du système, notamment awk, en offrant des possibilités plus vastes.
Ce qui permet d’avoir une structure aussi semblable, ce sont les options :
-n permet de boucler sur les lignes des fichiers passés en arguments ou de l’entrée standard,
-a active leur découpage automatique dans le tableau @F,
-l retire les fins de lignes en entrée et en remet en sortie,
,ドル = ' '; ajoute un espace comme séparateur de champ en sortie (pour faire comme awk).
Et aussi le fait que les lignes de l’entrée sont affectée à une variable implicite ($_) à laquelle sont appliquées par défaut les expressions régulières.
Bon, si je ne cherchais pas à coller à la version originale en awk, j’opterais pour parser explicitement l’entrée plutôt que de traîner un BEGIN, séparer les champs explicitement (pas la peine de le faire pour toutes les lignes, alors que seules certaines nous intéressent), je passerais en mode strict (ce qui implique de déclarer les variables, mais permet qu’on soit averti d’une faute de frappe dans un nom de variable)... Sans changer l’algorithme, ça ressemblerait à ça (j’ai commenté les spécificités de Perl dans le code) :
#!/usr/bin/perl -w# -w pour les avertissements ("warnings")usestrict;# Interdit certaines constructions pouvant correspondre à une erreur (variables# non déclarées, etc.).my$size=15;my$c=1;my($k,@t);# Si on ne précise rien, une variable scalaire est initialisée à undef et un# tableau à tableau vide.while(<>){# Cette construction parcoure les lignes de l’entrée en affectant la ligne# courante à la variable implicite $_/^KeyPress event/and$k=1;# Sans précision, une expression régulière s’applique à la variable# implicite (c’est pour ça qu’on l’appelle variable implicite...).if($k&&/^ root /){my@f=split;# Sans argument, split s’applique aussi sur $_.$f[5]=~s/,$//;$t[1+($c%$size)]=$f[5];if($c>$size){my$start=1+$c%$size;my$end=1+($c-$size+1)%$size;my$interval=$t[$start]-$t[$end];if($interval>0){print60000/ ($interval /$size)," BPM\n";}else{print"Too fast\n";}}++$c;$k=0;}}
Pourquoi j’utilise quelquefois (rarement) awk quand même ?
Parce que sa force est d’être installé en standard. Ça m’arrive de vouloir un script qui tourne tout de suite sur n’importe quel système (de type Unix), et que sur certaines distributions indigentes (ou systèmes indigents), Perl n’est pas installé par défaut (ou présent dans la version live).
Après, quand on veut un script vraiment passe partout (majorité des distributions Linux, systèmes *BSD, autres Unix), on ne peut pas compter sur les fonctionnalités avancées de GNU awk (pas communes à toutes les versions d’awk) et on peut oublier aussi bash, les *BSD ne l’ont pas forcément d’origine. Du coup, il faut se rabattre sur /bin/sh, mais le dénominateur commun entre bash et le shell des *BSD est déjà pas mal limité. Mais si on cible aussi OpenIndiana, c’est le drame (/bin/sh y correspond à un shell historique notoirement bogué et très limité, conservé pour garantir de ne pas mettre en défaut de vieux scripts que les utilisateurs ont pu développer).
On peut craindre que les mainteneurs d’une distribution aient l’idée de supprimer awk parce que c’est vieux et qu’ils fournissent bien mieux... sauf que leur truc bien mieux ne sera pas d’origine partout.
Alors, si on n’a plus que le shell, il permet toutefois de faire des opérations sur les chaînes, mais avec une syntaxe bien plus absconse que Perl, awk ou sed, et les plus pratiques ne sont pas supportées par tous les shells (voire par très peu).
« Le fascisme c’est la gangrène, à Washington comme en Russie. » — adapté de Renaud, Hexagone
[^] # Outils de base et awk vs Perl
Posté par Arthur Accroc . En réponse au journal taptempo.awk : une approche plus unix ?. Évalué à 6.
Mais quand on commence à vouloir croiser les données issues de plusieurs fichiers (ou sorties de processus) différents, les outils de base d’Unix avouent leurs limites : le principe du pipe, ça va bien tant qu’on n’a qu’une source... L’avantage de Perl par rapport à des outils Unix « pipés », c’est qu’on reste dans son script, on ne perd pas ses variables à chaque étape.
Bon, awk tient quand même la route plus longtemps que les autres outils de base.
Malgré cela, je ne l’utilise quasiment plus, parce que tout ce qu’on peut faire en awk, on peut le faire en Perl en à peine plus long, et même quasiment à l’identique si on veut*, mais que si jamais on veut faire d’autres trucs ensuite, avec Perl, on a toute la puissance du langage, de sa bibliothèque standard et de son dépôt (dont Time::HiRes, utilisé par TapTempo.pl)...
* Par exemple, on peut transcrire le script awk de ce journal simplement en :
Je vous invite à faire une comparaison avec la version awk du journal à l’aide de meld ou tkdiff ; ce n’est pas un hasard que ce soit si similaire : les premières versions de Perl visaient justement à remplacer le shell et les outils du système, notamment awk, en offrant des possibilités plus vastes.
Ce qui permet d’avoir une structure aussi semblable, ce sont les options :
-n permet de boucler sur les lignes des fichiers passés en arguments ou de l’entrée standard,
-a active leur découpage automatique dans le tableau @F,
-l retire les fins de lignes en entrée et en remet en sortie,
,ドル = ' '; ajoute un espace comme séparateur de champ en sortie (pour faire comme awk).
Et aussi le fait que les lignes de l’entrée sont affectée à une variable implicite ($_) à laquelle sont appliquées par défaut les expressions régulières.
Bon, si je ne cherchais pas à coller à la version originale en awk, j’opterais pour parser explicitement l’entrée plutôt que de traîner un BEGIN, séparer les champs explicitement (pas la peine de le faire pour toutes les lignes, alors que seules certaines nous intéressent), je passerais en mode strict (ce qui implique de déclarer les variables, mais permet qu’on soit averti d’une faute de frappe dans un nom de variable)... Sans changer l’algorithme, ça ressemblerait à ça (j’ai commenté les spécificités de Perl dans le code) :
Pourquoi j’utilise quelquefois (rarement) awk quand même ?
Parce que sa force est d’être installé en standard. Ça m’arrive de vouloir un script qui tourne tout de suite sur n’importe quel système (de type Unix), et que sur certaines distributions indigentes (ou systèmes indigents), Perl n’est pas installé par défaut (ou présent dans la version live).
Après, quand on veut un script vraiment passe partout (majorité des distributions Linux, systèmes *BSD, autres Unix), on ne peut pas compter sur les fonctionnalités avancées de GNU awk (pas communes à toutes les versions d’awk) et on peut oublier aussi bash, les *BSD ne l’ont pas forcément d’origine. Du coup, il faut se rabattre sur /bin/sh, mais le dénominateur commun entre bash et le shell des *BSD est déjà pas mal limité. Mais si on cible aussi OpenIndiana, c’est le drame (/bin/sh y correspond à un shell historique notoirement bogué et très limité, conservé pour garantir de ne pas mettre en défaut de vieux scripts que les utilisateurs ont pu développer).
On peut craindre que les mainteneurs d’une distribution aient l’idée de supprimer awk parce que c’est vieux et qu’ils fournissent bien mieux... sauf que leur truc bien mieux ne sera pas d’origine partout.
Alors, si on n’a plus que le shell, il permet toutefois de faire des opérations sur les chaînes, mais avec une syntaxe bien plus absconse que Perl, awk ou sed, et les plus pratiques ne sont pas supportées par tous les shells (voire par très peu).
« Le fascisme c’est la gangrène, à Washington comme en Russie. » — adapté de Renaud, Hexagone