Je ne cherchais pas à dire que c'est mieux que awk ou autre,
mais simplement de montrer que l'on peut se passer des pipes en bash et le gain en performances en est conséquent.
Sur de gros fichiers, il est évident que de faire des | grep , | awk ça rox.
Mais sur de petits fichiers et une machine lente, le pipe c'est lent (car fork si je ne me trompe pas).
Et si le processing fait appelle à d'autres outils du script bash pour inserer des trucs dynamiquement , définir des variables pour bash en fonction de certaines lignes, remplir un tableau (si si ça existe en bash) etc ..
Une pile de grep/awk n'est pas forcement plus efficace.
Et puis, le plus pénible avec ces tubes étant la difficulté à obtenir le code de retour de la première commande ce qui rend encors plus complexe la détection d'erreurs dans le script qui sont trop souvent négligées sous pretexte que ça n'arrive jamais.
>imagine que dans ton traitement tu fais appel a des grep, cut ou sed, sur un fichier de plusieurs milliers de lignes c'est l'horreur.
Si je montre comment éviter les grep, cut & autre, ce n'est pas pour en mettre dans le 'processing' de chaques lignes. Suis pas gros débile non plus, hein :-)
Utiliser un script shell pour traiter plusieurs milliers de lignes, c'est pas une super bonne idée non-plus.
[^] # Re: Y a pas que Bash dans la vie
Posté par petit_bibi . En réponse au journal Un meilleur shell. Évalué à 1.
mais simplement de montrer que l'on peut se passer des pipes en bash et le gain en performances en est conséquent.
Sur de gros fichiers, il est évident que de faire des | grep , | awk ça rox.
Mais sur de petits fichiers et une machine lente, le pipe c'est lent (car fork si je ne me trompe pas).
Et si le processing fait appelle à d'autres outils du script bash pour inserer des trucs dynamiquement , définir des variables pour bash en fonction de certaines lignes, remplir un tableau (si si ça existe en bash) etc ..
Une pile de grep/awk n'est pas forcement plus efficace.
Et puis, le plus pénible avec ces tubes étant la difficulté à obtenir le code de retour de la première commande ce qui rend encors plus complexe la détection d'erreurs dans le script qui sont trop souvent négligées sous pretexte que ça n'arrive jamais.
>imagine que dans ton traitement tu fais appel a des grep, cut ou sed, sur un fichier de plusieurs milliers de lignes c'est l'horreur.
Si je montre comment éviter les grep, cut & autre, ce n'est pas pour en mettre dans le 'processing' de chaques lignes. Suis pas gros débile non plus, hein :-)
Utiliser un script shell pour traiter plusieurs milliers de lignes, c'est pas une super bonne idée non-plus.