[pour des conseils généraux de script, voir les autres réponses]
Cette réponse concerne l'utilisation de programmes en ligne de commande et également de grandes chaînes d'entre eux.
Pour exécuter des chaînes de programmes CLI, et peut-être plusieurs chaînes en séquence, bash est le plus simple. Perl peut faire la même chose mais le langage est beaucoup plus difficile à apprendre et est beaucoup plus complexe, et comme beaucoup l'ont souligné, il est facile d'écrire du Perl intelligible.
Si vous parcourez des fichiers et des paramètres, bash est plus facile à démarrer b / c, vous pouvez prototyper dans le shell, puis copier dans un script et ajouter des tableaux et des boucles avec un minimum de surcharge.
Exemples de ce que je veux dire:
$ cat input.dat | numerical_model source_data ${SRC} grid_size ${GRID_SIZE} param1 ${P1} param2 ${P2} | tee ${OUTPUT} | plotter title ${TITLE} ylabel ${YLABEL} xlabel ${XLABEL} > ${OUTPUT_FIG}
$ cat ${OUTPUT} | stats_cmd bin_size ${BINSIZE} dist_type ${DIST_TYPE} | tee ${OUTPUT_STATS} | plotter plot_type ${PLOT_TYPE} title ${TITLE_STATS} > ${OUTPUT_FIG_STATS}
En bash, il est facile d'envelopper cela en quelques boucles sur certains de ces paramètres. pourtant , le code devient difficile à lire une fois que le script fait plus de quelques dizaines de lignes. --- imaginez 30 ensembles de commandes (quelques lignes chacune) pour trente tracés de données différents ---
Perl et Python pourraient être meilleurs pour les gros scripts car ils ont une syntaxe plus propre pour les boucles et les variables, mais les commandes bash doivent être générées sous forme de chaînes, exécutées en tant que sous-processus et stdin, stdout capturé. Cela peut être fait, mais il ne peut pas remplacer complètement l'environnement shell natif.
Si les obus avaient une meilleure langue, tout cela serait évité.