Ma règle d'or de la programmation shell est de traiter aussi peu de données que possible avec le shell
C'est toi que ça regarde.
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.
Pour utiliser différents outils de workflow (ou affilié) le shell est assez mauvais pour ça (utiliser plus d'entrée et de sortie que ceux prévu en standard n'est pas très pratique, complexité de créer des routes avec plus d'une entrée et plus d'une sortie, aucun mécanisme de monitoring de ce que se passe, difficulté de debugage (beaucoup de monde écris cmd1|cmd2|cmd3 sans s'intéresser à gérer les erreurs de la commande cmd2, etc).
Bref ce n'est AMHA pas parce qu'il fait des pipes que ça en fait un outil de description de workflow, ou du moins il a à peu près autant de défaut pour décrire des workflow que pour gérer des données.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: pure bash et un peu long
Posté par barmic . En réponse au journal Lire de fichiers de configuration depuis un script shell. Évalué à 3.
C'est toi que ça regarde.
Pour utiliser différents outils de workflow (ou affilié) le shell est assez mauvais pour ça (utiliser plus d'entrée et de sortie que ceux prévu en standard n'est pas très pratique, complexité de créer des routes avec plus d'une entrée et plus d'une sortie, aucun mécanisme de monitoring de ce que se passe, difficulté de debugage (beaucoup de monde écris cmd1|cmd2|cmd3 sans s'intéresser à gérer les erreurs de la commande cmd2, etc).
Bref ce n'est AMHA pas parce qu'il fait des pipes que ça en fait un outil de description de workflow, ou du moins il a à peu près autant de défaut pour décrire des workflow que pour gérer des données.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)