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


Nous faisons tout notre script avec Bash jusqu'ici, mais je commence à me sentir un peu bête à ce sujet. Bien que nous puissions bien sûr faire tout ce que nous voulons avec Bash (c'est très puissant), je commence à me demander si nous ne devrions pas utiliser un langage de script correct (dans notre cas, probablement Ruby).

Comment décidez-vous quand utiliser Perl / Python / Ruby sur Bash pour un script? Je ne pense pas qu'un script d'initialisation avec Ruby ait du sens, mais qu'en est-il d'un script légèrement plus long qui ajoute des comptes de messagerie?


64
2018-04-21 02:37


origine


Si vous pouvez le faire en utilisant l'un ou l'autre, est-ce vraiment important? Le choix n'est intéressant que si le script qui en résulte présente des différences. Par exemple, le temps d'exécution peut différer considérablement (pas un problème lorsque les comptes de messagerie). - Dennis


Réponses:


Étant donné un problème que les deux peuvent résoudre, vous voudrez utiliser celui avec lequel vous êtes le plus à l'aise. En fin de compte, il y a beaucoup de petits détails et seule l'expérience peut vous apprendre à les voir.

Bash est un langage de script généraliste, tout comme Python, Ruby, Perl, mais chacun a ses points forts sur le reste. Perl excelle en analyse de texte, Python prétend être le plus élégant de la bande, les scripts Bash sont excellents pour les choses à la mode, si vous voyez ce que je veux dire, et Ruby ... eh bien, Ruby est un peu spécial de manières.

Cependant, les différences entre eux ne comptent vraiment qu'une fois que vous avez une bonne expérience de script sous votre ceinture. Je vous suggère de choisir une langue et de la pousser à ses limites avant de passer à la suivante. Vous pouvez faire beaucoup dans un script shell, plus que ce que la plupart des gens admettraient. Toute langue est aussi difficile que vous le souhaitez. Après avoir écrit quelques choses, chaque langue est "facile" pour vous.

Être familier avec le shell est rapidement rentable si vous vivez sous Linux, alors peut-être voulez-vous commencer avec ça. Si vous trouvez une tâche impossible ou peu pratique à résoudre dans un script shell, utilisez autre chose.

Gardez également à l'esprit que l'apprentissage des scripts shell est très simple. Le véritable pouvoir réside dans d'autres programmes, comme awk, sed, tr et al.


37
2018-04-21 03:33



J'ai beaucoup d'expérience avec les scripts bash, comme Ruby, mais parfois je ne sais toujours pas quoi utiliser. Choisir en fonction de ses préférences personnelles à ce moment semble stupide. Mais vous avez raison, je me demanderai ce que je veux faire et choisir le meilleur outil pour le travail. - futlib
Personnellement, j'utiliserai une échelle de langues que je connais bien, dans un ordre croissant de complexité et de puissance, et utiliserai le plus simple possible. Mais vraiment, la seule façon de savoir avec certitude est d'écrire votre script dans toutes les langues et de comparer les résultats. C'est plus que de la certitude. Après quelques années d'écriture de scripts, vous rencontrerez la plupart des "types de problèmes" et vous saurez quelle langue les a bien résolues. - mkaito
Je voulais juste ajouter que l'utilisation de petits programmes dans le paquet GNU coreutils (comme tr, sort, uniq) et leur distribution permet d'accomplir beaucoup de tâches. - GMaster


TL; DR - utilisez bash seulement pour installer une meilleure langue (si elle 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 sur la ligne de commande à la main, sans erreur, ne créez pas de script avec bash / shell.

C'est 2015, donc je considérerais ce qui suit:

  1. surcharge de mémoire

    • La surcharge de mémoire d'exécution Ruby / Python par rapport à bash est minime (à cause des bibliothèques partagées), alors que l'on ne peut probablement pas maintenir un script bash non trivial (c'est-à-dire avec plus de 100 lignes).
  2. le temps de démarrage

    • Le démarrage de Ruby / Python peut être un peu plus lent, mais il y a des chances que vous ne lanciez pas beaucoup de processus Ruby / Python dans une boucle serrée 100 fois par seconde (si vous avez ce genre de besoins, bash / shell est trop de frais généraux de toute façon et vous aurez probablement besoin de passer à C / C ++)
  3. performance

    • presque tous les traitements de données classiques seront plus rapides dans Ruby / Python - ou du moins comparables (ou, de toute façon, vous avez besoin de C / C ++ / Haskel / OCaml / peu importe)
    • la performance réelle / goulot d'étranglement dans l'exécution (ou même la productivité) sera presque plus jamais être "un manque d'utilisation de bash / shell" (même Ubuntu basculer dash pour le démarrage montre comment bash est réellement le problème - et un busybox est probablement le seul cas d'utilisation, car il 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 / télécharger ou stocker autre chose
    • exécuter d'autres processus pour effectuer le travail (comme sed / awk / grep) est en fait plus lent que d'appeler une méthode sur un objet actif en mémoire
  4. productivité

    • il est trop facile de faire des erreurs dans Bash / shell par rapport aux méthodes, paramètres, variables et exceptions "réels" de Ruby / Python
    • Agile est courant, alors que Bash ne le supporte pas (manque de capacités de tests unitaires, bibliothèques, OO, modularité, linting, introspection, journalisation, métaprogrammation; presque impossible à refacturer sans casser quelque chose)
    • beaucoup trop d'incompatibilités avec d'autres shells, les variables d'environnement mineures peuvent complètement casser un script (et certains outils dev-ops importants comme Puppet ignorent les lignes shebang et transmettent ou réécrivent les variables shell importantes), alors que Ruby / Python chemins même pour les changements majeurs de version
    • apprendre un nouveau langage prend une fraction du temps ou bien déboguer des scripts shell en raison de problèmes spécifiques au shell (notamment - noms de variables, pas de booléens, pas d'exceptions, etc.)
    • même les scripts de démarrage sont une mine terrestre (notamment parce qu'ils peuvent échouer pendant système démarrage), et compte tenu des failles de sécurité récentes avec bash, il vaut peut-être mieux utiliser plain C (avec de bonnes bibliothèques) - oui, C nécessite la compilation, la configuration, etc. , puis emballer quand même.
    • tout ce qui est disponible avec sed / awk / grep est probablement déjà intégré à Ruby / Python - sans qu'il s'agisse d'une dépendance, ou de "différences" entre les versions de ces outils entre les plates-formes (alors, si cela fonctionne votre installer)
  5. la sécurité d'emploi
    • A quoi sert-il d'obtenir un emploi que vous n'aimez pas? (à moins que vous n'aimiez passer toutes ces heures difficiles à déboguer mais bogues de script shell faciles à faire)

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

Et probablement que l'installation de Ruby / Python n'a même pas besoin d'un script bash (à l'exception de busybox, certains outils système dépendent de la présence de Python / Perl).

Et chaque fois que vous écrivez un script shell, vous "faites" exactement cela - au lieu d’apprendre quelque chose de plus puissant / productif.

Pourquoi les gens utilisent-ils Bash aujourd'hui? Parce que c'est une habitude terrible, difficile à casser. Un script est rarement «fini pour toujours» après les premières minutes - peu importe à quel point les gens ont tendance à penser de cette façon. Avec le "il est le dernier bogue dans ce script" erreur.

Conclusion: utilisez bash / shell uniquement lorsque vous êtes absolument forcé aimer ~/.bashrc, busybox), car il est presque jamais "le bon outil pour le travail" de nos jours.


46
2017-07-04 13:59



Je suis content que quelqu'un soit d'accord unix.stackexchange.com/questions/350266/... - Marco Prins


J'utilise bash lorsque mon objectif principal est la gestion des fichiers. Cela peut inclure le déplacement, la copie et le renommage de fichiers, ainsi que l'utilisation de fichiers en entrée pour d'autres programmes ou le stockage d'autres sorties de programme dans des fichiers. J'écris rarement du code bash qui examine réellement le contenu d'un fichier ou génère la sortie pour é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 à partir de fichiers, de traiter ces données d'une manière ou d'une autre et d'écrire des sorties dans des fichiers. Si je me retrouve à utiliser (en Perl) le system commande, back ticks ou (en python) le subprocess module trop extensif, je considère écrire le script en bash. D'un autre côté, je commence parfois à ajouter tellement de fonctionnalités à un script bash qu'il serait plus judicieux de le réécrire dans Perl / python plutôt que de gérer le support limité (par comparaison) de la portée, des fonctions, des structures de données, etc. .


27
2018-04-21 18:19



J'ai aussi utilisé t0 sur Bash à chaque fois que la lecture / génération de texte était requise, mais après =~ opérateur pris en charge par [[ ]] Je m'aimais un peu de Bash pour simple lecture de fichier - Freedom_Ben


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

  • S'il n'y a pas d'arguments à transmettre, c'est probablement un script shell.
  • S'il n'y a pas beaucoup de logique de contrôle (à part une boucle unique ou si / sinon), c'est probablement un script shell.
  • Si la tâche est l'automatisation des instructions de ligne de commande, c'est presque certainement un script shell.

13
2018-04-09 23:31





J'ai trouvé cette analyse Perl versus Bash utile ...

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

Pour plus de commodité, je recopie un résumé de cet auteur lorsque 1) bash est meilleur et 2) lorsque perl est meilleur conclusion ...

Quand Bash est mieux ...

  • Échec du travail
  • Commandes à la sortie
  • Traitement des lignes de sortie du travail
  • Ici des documents
  • Equivalences de fichiers
  • Comparaison des horodatages de fichiers
  • Expansion Tilde

Quand Perl est mieux ...

Perl bat toujours la merde pour la plupart des applications. Les raisons pour lesquelles je préférerais Perl incluent (mais ne sont pas limitées à):

  • Ça va être plus rapide. Principalement parce que je n'ai pas vraiment besoin de lancer de nouveaux processus pour beaucoup de choses que je veux faire (basename et dirname étant les exemples les plus évidents, mais généralement, cut, grep, sort et wc peuvent également être éliminés).
  • La gestion des chaînes en bash est rudimentaire au mieux, et la totalité de $ IFS est très encombrante.
  • Les conditions dans les scripts shell peuvent être difficiles.
  • Citer dans les scripts shell peut être un cauchemar.
  • La déclaration de cas de bash laisse beaucoup à désirer au-delà des cas simples (NPI).
  • Les tableaux en bash sucent. Hash in bash (en supposant que votre bash est assez nouveau pour les avoir du tout) sucer encore plus fort.
  • Une fois que le traitement des fichiers ou la sortie de la commande dépasse le simple cas que j'ai énuméré ci-dessus, Perl commence vraiment à fumer.
  • CPAN.

Donc, ce n'est pas comme si bash allait bientôt remplacer Perl. Mais je trouve toujours qu'après toutes ces années, un simple script shell peut parfois être plus simple qu'un simple script Perl. Comme je le disais, je salue toutes les tentatives de me convaincre du contraire. Mais encore une fois, il n’ya rien de mal à avoir quelques outils différents dans votre boîte à outils.


8
2018-04-24 15:38



Fait intéressant, dans Ruby, tous les points (?) Ne s’appliquent pas, car Ruby contient at_exit (), realpath (), expand_path (), stat (), heredocs et des exceptions (fail "error" unless system("foobar")). - Cezary Baginski


Dans mon expérience, bash versus python est un compromis entre le temps de développement et la flexibilité. Une solution rudimentaire à un problème peut généralement être établie plus rapidement dans un script bash que dans un script python.

Python aura tendance à vous faire réfléchir davantage à la structure de votre solution que le script bash équivalent. Python a plus de pouvoir expressif qu'un script bash et a donc tendance à évoluer et à se modifier au fil du temps. Il reste également plus lisible en général.

Bash est plus proche du système de fichiers et peut être idéal pour les premières solutions préliminaires à des problèmes qui ne sont PAS bien définis. Pour cette raison, un script bash pourrait être un bon premier choix pour prototyper quelque chose avec l'intention de le porter sur python une fois le problème mieux compris.


4
2017-09-30 15:42





Bash est un shell Unix, il comprend un langage de script. C'est plutôt un processeur de commandes. vous contrôlez la façon dont vous exécutez les commandes, vous les exécutez réellement.

Perl / Ruby / Python sont des langages d'usage général.

Lorsque vous voulez un script shell, vous utilisez Bash

Si vous souhaitez une tâche plus complexe ou non liée au shell. Utilisez Python etc.

Je ne comparerais jamais ces langues en fait. Python etc. sont portables. Vous pouvez les exécuter n'importe où. Bash est pour Unix uniquement.

Python etc. a des tonnes de bibliothèques réutilisables pour résoudre des millions de tâches.

C'est presque pareil si vous demandez. "Quand utiliser Paint et quand utiliser Photoshop"

Pour le traitement des e-mails, j'utiliserais encore Ruby, car il contient de nombreuses bibliothèques réutilisables.

Mais le meilleur moyen serait de combiner bash et rubis. Ce serait bien. Comme vous créez un script de traitement de courrier électronique dans ruby ​​et script bash invoquer ce script ruby ​​et exécuter d'autres commans ds.

Donc, chaque fois que vous avez besoin d'un processeur de commandes, vous utilisez bash. Vous exécutez des commandes Unix et les contrôlez.


3
2018-04-21 03:03



Le sous-ensemble de script de Bash est tout aussi général que tout langage de script à usage général. Ajoutez des programmes généraux comme sed dans le mix, et vous êtes couvert pour 90% de tous les besoins de script que vous aurez jamais. - mkaito
bash est un processeur de commandes, donc sa puissance est d'exécuter d'autres commandes et programmes unix dans leurs scripts. Comme vous avez mentionné sed, etc. Il demande quand choisir une langue - bakytn
Le shell est un lanceur de programmes glorifié, mais ses capacités de script vont bien au-delà. Je vous suggère d’apprendre de vrais scripts shell. - mkaito
Je peux dormir par terre mais je préfère le faire sur un lit. Les langues ne peuvent pas être comparées, elles ont des buts différents. - bakytn
Eh bien, si Bash est le sol, quelque chose comme Haskell doit être un clou :-) - mkaito


Article très biaisé.

Je ne trouve pas que bash soit si difficile à déboguer. Python est souvent beaucoup trop rigide, alors que bash vous permet d'être très créatif. Si vous êtes un bon penseur, vous apprécierez bash.

Je lance des scripts bash sur des millions de lectures de séquençage d'ADN dans des milliers de fichiers, et ça me va très bien. Et contrairement à ce que tout le monde dit, les mêmes versions des scripts en C ++ ne sont pas vraiment plus rapides (en quelques minutes, elles les séparent).

Je pense que bash, tout comme perl, n'est pas le plus convivial ni le plus facile à lire. Cela fait fuir les gens parce que la plupart des gens ne sont pas de grands penseurs abstraits. Mais les programmeurs plus brillants et plus créatifs ont tendance à l’aimer et à l’utiliser fréquemment. Si vous vous connaissez et que vous savez que vous avez un cerveau, ne soyez pas effrayé par bash. Si vous êtes un penseur de base, restez peut-être fidèle à quelque chose comme Python. À chacun son


1
2017-11-09 21:09





Du "livre de lamas"

Perl essaie de combler l’écart entre la programmation de bas niveau (comme en C ou C ++ ou l’assemblage) et la programmation de haut niveau (telle que la programmation "shell" [par exemple, bash]). La programmation de bas niveau est généralement difficile à écrire et moche, mais rapide et illimitée; il est difficile de battre la vitesse d'un programme bien écrit de bas niveau sur une machine donnée. Et il n'y a pas grand chose que vous ne pouvez pas faire là-bas. La programmation de haut niveau, à l'autre extrême, a tendance à être lente, dure, laide et limitée; il y a beaucoup de choses que vous ne pouvez pas faire du tout avec la programmation shell ou batch s'il n'y a pas de commande sur votre système qui fournit les fonctionnalités nécessaires. Perl est facile, presque illimité, le plus souvent rapide et plutôt moche.


0
2017-09-08 21:02