Quand utiliser Bash et quand utiliser Perl/Python/Ruby ?

TL;DR - utiliser bash sólo pour installer un meilleur langage (s'il n'est pas déjà disponible), sinon vous perdez un temps humain précieux et irrécupérable. Si vous ne pouvez pas le faire à la main en ligne de commande sans faire d'erreurs, ne faites pas de script avec bash/script.

On est en 2015, donc je considérerais les éléments suivants :

1. surcharge de mémoire

   • La surcharge mémoire de l'exécution de Ruby/Python comparée à celle de bash est minuscule (à cause des bibliothèques partagées), tandis que l'on ne peut probablement pas maintenir un script bash non trivial de toute façon (c'est-à-dire un script de plus de 100 lignes) - l'utilisation de la mémoire n'est donc pas un facteur.

2. temps de démarrage

   • Le démarrage de Ruby/Python peut être un tout petit peu plus lent, mais il y a de fortes chances que vous n'ayez pas à exécuter des tas de processus Ruby/Python complets dans une boucle serrée 100 fois par seconde (si vous avez ce genre de besoins, bash/Shell est de toute façon trop surchargé et vous devrez probablement passer à C/C++).

3. performance

   • presque tous les traitements de données typiques seront plus rapides en Ruby/Python - ou au moins comparables (ou, vous avez besoin de C/C++/Haskel/OCaml/quelque chose de toute façon)
   • le véritable goulet d'étranglement dans l'exécution (ou même la productivité) sera presque jamais, jamais être "un manque d'utilisation de bash/Shell" (même Ubuntu changeant dash pour le démarrage montre comment bash est en fait le problème - et une busybox est probablement le seul cas d'utilisation, parce qu'il y a est rien de plus que 'bash' et 'vi' pour écrire et exécuter du code, et il n'y a souvent aucun moyen d'ajouter/de télécharger ou de stocker autre chose)
   • L'exécution d'autres processus pour faire le travail (comme sed/awk/grep) est en fait une magnitude plus lente que l'appel d'une méthode sur un objet vivant en mémoire.

4. productivité

   • il est trop facile de faire des erreurs en Bash/Shell par rapport à l'utilisation de "vraies" méthodes, paramètres, variables et exceptions en Ruby/Python
   • Agile est un courant dominant, alors que Bash ne le supporte pas (manque de capacités de test unitaire, de bibliothèques, d'OO, de modularité, de linting, d'introspection, de journalisation, de métaprogrammation ; presque impossible de remanier sans casser quelque chose).
   • beaucoup trop d'incompatibilités avec d'autres shells, des variables d'environnement mineures peuvent complètement casser un script (et certains outils importants de dev-ops comme Puppet ignorent les lignes shebang et transmettent ou réécrivent d'importantes variables script), alors que Ruby/Python ont des chemins de migration bien définis et relativement fluides, même pour les changements de version majeurs.
   • l'apprentissage d'un nouveau langage ne prend qu'une fraction du temps passé à déboguer Shell Shell en raison de problèmes spécifiques à Shell (notamment - noms de variables, pas de booléens, pas d'exceptions, etc.)
   • même les scripts de démarrage sont une mine ( notamment car ils peuvent tomber en panne pendant système startup), et compte tenu des récentes failles de sécurité avec bash, vous feriez peut-être mieux d'utiliser le C brut (avec de bonnes bibliothèques) - oui, le C a besoin de compilation, de configuration, etc, mais même un simple Shell Shell peut avoir besoin d'un dépôt, puis d'un versioning, puis d'un packaging de toute façon.
   • tout ce qui est disponible avec sed/awk/grep est probablement déjà intégré dans Ruby/Python - sans qu'il s'agisse d'une dépendance, ou de "différences" entre les versions de ces outils sur les plates-formes (et si ça marche sous votre installation)
5. sécurité de l'emploi
   • quel est l'intérêt d'obtenir un emploi que vous n'aimez pas ? (sauf si vous aimez passer toutes ces heures difficiles à déboguer mais triviales à réaliser Shell Shell bugs).

Je trouve qu'il n'y a aucune raison d'utiliser Bash/Shell si Ruby/Python est installé.

Et probablement que l'installation de Ruby/Python ne nécessite même pas un bash script en premier lieu (à l'exception de busybox, certains outils système dépendent de la présence de Python/Perl de toute façon).

Et chaque fois que vous écrivez un Shell Shell, vous vous "entraînez" à faire exactement cela - au lieu d'apprendre quelque chose de plus puissant/productif.

Pourquoi les gens utilisent-ils Bash de nos jours ? Parce que c'est une habitude terrible et difficile à perdre. Un script est rarement "terminé pour toujours" après les premières minutes - même si les gens ont fortement tendance à penser de cette façon. Tout comme le sophisme du "c'est le dernier bogue de ce script".

Conclusion : n'utilisez bash/Shell que si vous êtes absolument obligé de le faire. forcé à (comme ~/.bashrc , busybox), parce qu'il est presque jamais "le bon outil pour le bon travail" de nos jours.

J'utilise bash lorsque mon objectif principal est la manipulation de fichiers. Cela peut inclure le déplacement, la copie et le renommage de fichiers, ainsi que l'utilisation de fichiers en entrée d'autres programmes ou le stockage de la sortie d'autres programmes dans des fichiers. J'écris rarement du code bash qui examine réellement le contenu d'un fichier ou génère la sortie à écrire dans un fichier ; je laisse cela aux autres programmes (que je peux écrire en Perl ou Python) que je lance via bash.

J'utilise Perl et Python lorsque mon objectif principal est de lire des données dans des fichiers, de traiter ces données d'une manière ou d'une autre et d'écrire les résultats dans des fichiers. Si je me retrouve à utiliser (en Perl) la fonction system les tics arrière ou (en Python) la commande subprocess de manière trop extensive, j'envisage d'écrire le script en bash. D'un autre côté, je commence parfois à ajouter tellement de fonctionnalités à un script en bash qu'il est finalement plus logique de le réécrire en Perl/Python plutôt que de s'occuper du support limité (en comparaison) de bash pour la détermination de la portée des variables, les fonctions, les structures de données, etc.

J'aime les critères énoncés dans cet article de blog .

• S'il n'y a pas d'arguments à passer, il s'agit probablement d'un Shell Shell.
• S'il n'y a pas grand-chose pour la logique de contrôle (à part une simple boucle ou if/else), il s'agit probablement d'un Shell Shell.
• Si la tâche est l'automatisation d'instructions en ligne de commande, c'est presque certainement un Shell Shell.

J'ai trouvé cette analyse de Perl contre Bash utile...

http://blogs.perl.org/users/buddy_burden/2012/04/perl-vs-Shell-Shell.html

Pour des raisons de commodité, je copie un résumé des conclusions 1) when bash is better et 2) when perl is better de cet auteur...

Quand Bash est meilleur...

• Échec au travail
• Commandes de sortie
• Traitement des lignes de sortie des travaux
• Documents ici
• Équivalences de fichiers
• Comparaisons d'horodatage de fichiers
• Tilde Expansion

Quand Perl est meilleur...

Perl est toujours plus performant que bash pour la plupart des applications. Les raisons pour lesquelles je pourrais préférer Perl incluent (mais ne sont pas limitées à) :

• Ça va être plus rapide. Principalement parce que je n'ai pas besoin de lancer de nouveaux processus pour la plupart des choses que je veux faire (basename et dirname étant les exemples les plus évidents, mais généralement cut, grep, sort et wc peuvent tous être éliminés également).
• La gestion des chaînes de caractères dans bash est au mieux rudimentaire, et toute l'histoire de $IFS est très compliquée.
• Les conditionnels dans les Shell Shell peuvent être bancals.
• La citation dans Shell Shell peut être un cauchemar.
• L'exposé du cas de Bash laisse beaucoup à désirer au-delà des cas simples (NPI).
• Les tableaux en bash sont nuls. Les hachages dans bash (en supposant que votre bash soit assez récent pour les avoir) sont encore plus nuls.
• Dès que le traitement des fichiers ou de la sortie des commandes dépasse le cas simple que j'ai énuméré ci-dessus, Perl commence à vraiment fumer bash.
• CPAN.

Ce n'est donc pas comme si bash allait prendre le relais de Perl de sitôt. Mais je trouve encore, après toutes ces années, que bien souvent un simple Shell Shell peut parfois être plus simple qu'un simple Shell Perl. Comme je le dis, je suis ouvert à toute tentative de me convaincre du contraire. Mais, là encore, il n'y a rien de mal à avoir quelques outils différents dans sa boîte à outils.