Quand utiliser Bash et quand utiliser Perl/Python/Ruby?
Nous faisons tous nos scripts avec Bash jusqu'à présent, mais je commence à me sentir un peu ridicule. Bien que nous puissions bien sûr faire tout ce que nous voulons avec Bash (c'est assez puissant), je commence à me demander si nous ne devrions pas utiliser un langage de script approprié (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 init avec Ruby ait du sens, mais qu'en est-il d'un script légèrement plus long qui ajoute des comptes de messagerie?
Étant donné un problème que les deux peuvent gérer, 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 à usage général, tout comme Python, Ruby, Perl, mais chacun a des points forts différents. Perl excelle en analyse de texte, Python prétend être le plus élégant du groupe, les scripts Bash sont excellents en "piping stuff around", si vous voyez ce que je veux dire, et Ruby ... eh bien, Ruby est un peu spécial en beaucoup de façons.
Cependant, les différences entre eux ne comptent vraiment que lorsque vous avez une bonne expérience de scripting à votre actif. Je vous suggère de choisir une langue et de la pousser à la limite avant de passer à la suivante. Vous pouvez faire beaucoup dans un script Shell, plus que la plupart des gens ne l’admettraient. Toute langue est aussi difficile que vous le souhaitez. Après avoir écrit quelques mots, chaque langue est "facile" pour vous.
Être familiarisé avec le shell rapporte rapidement si vous vivez sous Linux, alors vous voudrez peut-être commencer par cela. Si vous trouvez une tâche impossible ou impraticable à résoudre dans un script Shell, utilisez autre chose.
N'oubliez pas non plus que l'apprentissage des scripts Shell est très simple. Le véritable pouvoir de ce logiciel réside dans d’autres programmes, tels que awk, sed, tr, et al.
TL; DR - utilisez bash only pour installer une meilleure langue (si elle n’est pas déjà disponible), sinon vous perdez un temps précieux et irrécupérable. Si vous ne pouvez pas le faire manuellement sur la ligne de commande sans commettre d'erreur, n'utilisez pas bash/Shell pour écrire un script.
Nous sommes en 2015, je considérerais donc ce qui suit:
surcharge de mémoire
- La surcharge de la mémoire d'exécution de Ruby/Python par rapport à bash est minime (à cause des bibliothèques partagées), alors qu'il est probablement impossible de gérer un script bash non trivial (de toute façon, c'est-à-dire avec un nombre supérieur à 100 lignes) - l'utilisation de la mémoire n'est donc pas un facteur.
le temps de démarrage
- Le démarrage de Ruby/Python est peut-être un peu plus lent, mais il est peu probable que vous exécutiez beaucoup de processus Ruby/Python complets dans une boucle serrée 100 fois par seconde (si vous avez ce type de besoins, bash/Shell de toute façon trop de temps et vous aurez probablement besoin de passer en C/C++)
performance
- presque tous les traitements de données typiques seront plus rapides en Ruby/Python - ou du moins comparables (ou, vous avez besoin de C/C++/Haskel/OCaml/peu importe de toute façon)
- la performance réelle/le goulot d'étranglement dans l'exécution (ou même la productivité) sera presque jamais jamais sera "un manque d'utilisation de bash/Shell" (même le tiret de commutation Ubuntu pour le démarrage montre à quel point bash est réellement le problème - et une boîte occupée est probablement le seul cas d'utilisation, car n'est rien d'autre 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)
- exécuter d'autres processus pour faire le travail (comme sed/awk/grep) est en réalité d'une ampleur inférieure à celle d'appeler une méthode sur un objet actif en mémoire
productivité
- il est trop facile de faire des erreurs dans Bash/Shell par rapport à l'utilisation de "vraies" méthodes, paramètres, variables et exceptions en Ruby/Python
- Agile est la norme, alors que Bash ne la prend pas en charge (manque de capacités de tests unitaires, de bibliothèques, d’OO, de modularité, de peluches, d’introspection, de journalisation, de métaprogrammation; il est presque impossible de refactoriser 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 de développement importants tels que Puppet ignorent les lignes Shebang et transmettent ou réécrivent des variables Shell importantes), tandis que Ruby/Python a une migration relativement bien définie. chemins même pour les changements de version majeurs
- l'apprentissage d'une nouvelle langue prend une fraction du temps nécessaire au débogage des scripts 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 terrestre ( en particulier car ils peuvent échouer pendant système démarrage), et étant donné les failles de sécurité récentes de bash, il vaut peut-être mieux utiliser un langage C clair (avec de bonnes bibliothèques) - oui, C a besoin de la compilation, de la configuration, etc., mais même un simple script Shell peut nécessiter un référentiel, puis la gestion des versions, puis le conditionnement de toute façon.
- tout ce qui est disponible avec sed/awk/grep est probablement déjà intégré à Ruby/Python - sans que cela soit une dépendance ou des "différences" entre les versions de ces outils sur toutes les plates-formes (que faire si cela fonctionne sur votre setup)
- la sécurité d'emploi
- à quoi sert-il d'obtenir un emploi que vous n'aimez pas? (à moins que vous n'aimiez passer toutes ces heures difficiles à corriger mais simples à créer des bogues de script Shell)
Je trouve qu'il n'y a aucune raison d'utiliser Bash/Shell si vous avez installé Ruby/Python.
Et obtenir Ruby/Python installé n’a probablement 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 "pratiquez" exactement ce que vous faites - 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 à rompre. Un script est rarement "fini pour toujours" après les premières minutes - peu importe à quel point les gens ont tendance à penser ainsi. Avec l'erreur "c'est le dernier bogue de ce script".
Conclusion: utilisez bash/Shell uniquement lorsque vous êtes absolument forcé à (comme ~/.bashrc, busybox), car c'est presque jamais "le bon outil pour le travail" de nos jours.
J'utilise bash lorsque mon objectif principal est la gestion de fichiers. Cela peut inclure le déplacement, la copie et le changement de nom de fichiers, ainsi que l'utilisation de fichiers en tant qu'entrée pour d'autres programmes ou le stockage de la sortie d'un autre 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 à écrire dans un fichier; Je laisse cela aux autres programmes (que je peux écrire en Perl ou en 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 les traiter d'une manière ou d'une autre et d'écrire les résultats dans des fichiers. Si je me trouve à utiliser (en Perl) la commande system, les ticks arrières ou (en python) le module subprocess de manière trop intensive, j'envisage d'écrire le script en bash. D'un autre côté, je commence parfois à ajouter tellement de fonctionnalités à un script bash qu'il est finalement plus logique de les réécrire en Perl/python plutôt que de gérer le support limité (par comparaison) de bash pour l'étendue 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 à transmettre, il s'agit probablement d'un script Shell.
- S'il n'y a pas beaucoup de choses pour la logique de contrôle (à part une boucle ou si/sinon), c'est probablement un script Shell.
- Si la tâche consiste à automatiser des instructions de ligne de commande, il s’agit presque certainement d’un script Shell.
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 copie un résumé de l'auteur 1) lorsque bash présente de meilleurs résultats et 2) lorsque Perl constitue une meilleure conclusion ...
Quand bash va mieux ...
- Echec du travail
- Commandes à la sortie
- Traitement des lignes de sortie
- Ici les documents
- Equivalences de fichiers
- Comparaisons d'horodatage de fichier
- Expansion Tilde
Quand Perl va mieux ...
Perl bat toujours la merde de 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 réellement besoin de démarrer de nouveaux processus pour beaucoup des choses que je veux faire (basename et dirname étant les exemples les plus évidents, mais généralement couper, grep, trier et wc peuvent également être éliminés).
- La gestion des cordes à bash est au mieux rudimentaire, et tout ce qui concerne $ IFS est super-maladroit.
- Les conditions dans les scripts de shell peuvent être négligées.
- Citer dans des 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 sucer. Les hachages dans bash (en supposant que votre bash soit suffisamment récente pour les avoir du tout) sont encore plus difficiles à sucer.
- Une fois que le traitement des fichiers ou de la sortie de la commande dépasse le cas simple que j'ai énuméré ci-dessus, Perl commence vraiment à fumer.
- CPAN.
Donc, ce n’est pas comme si bash allait bientôt prendre le relais de Perl. Mais je trouve toujours, après toutes ces années, qu’un simple script Shell peut parfois être plus simple qu’un simple script Perl. Comme je le dis, 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.
D'après mon expérience, bash versus python est un compromis entre temps de développement et flexibilité. Une solution rudimentaire à un problème peut généralement être établie dans un script bash plus rapidement que dans un script python.
Python aura tendance à vous faire réfléchir davantage sur la structure de votre solution que le script bash équivalent. Python a plus de pouvoir expressif qu'un script bash et tend donc à évoluer et à mieux se modifier au fil du temps. Il reste aussi plus lisible en général.
Bash est plus proche du système de fichiers et peut s'avérer très utile pour les premières ébauches de solutions à des problèmes qui ne sont PAS bien définis. Pour cette raison, un script bash peut être un bon premier choix pour prototyper quelque chose avec l'intention de le porter en python une fois que le problème est mieux compris.
Bash est un shell Unix qui comprend un langage de script. C'est plutôt un processeur de commande. vous contrôlez la façon dont vous exécutez les commandes, vous les exécutez réellement.
Perl/Ruby/Python sont des langages à usage général.
Quand vous voulez un script shell, vous utilisez Bash
Si vous voulez une tâche plus complexe ou non liée à Shell. Utilisez Python etc.
Je ne comparerais jamais ces langues en réalité. Python etc. sont portables. Vous pouvez les exécuter n'importe où. Bash est uniquement pour Unix.
Python, etc. ont des tonnes de bibliothèques réutilisables qui résolvent des millions de tâches.
C'est presque pareil si vous le demandez. "Quand utiliser Paint et quand utiliser Photoshop"
Pour le traitement des courriels, j’utiliserais encore Ruby, car il contient de nombreuses bibliothèques réutilisables.
Mais le meilleur moyen serait de combiner bash et Ruby. Ce serait juste. Comme vous créez un script de traitement de courrier électronique en Ruby, un script bash invoque ce script Ruby et exécute d’autres commandes.
Donc, chaque fois que vous avez besoin d'un processeur de commande, vous utilisez bash. Vous exécutez des commandes unix et les contrôlez.
MISE À JOUR après 7 ans (mars 2019)
Bien que l'essentiel de ma réponse n'ait pas changé, je voudrais le souligner.
Bash est également un puissant langage de script. Pour le traitement de texte, cela pourrait être un choix légitime.
S'il vous plaît lire les commentaires de mkaito ci-dessous. Ils sont tous complètement vrais.
Les scripts shell tels que bash, ksh, zsh, sh et fish sont notoirement surprenants, comparés aux langages généraux de haut niveau tels que Ruby, Python ou Perl. Bien qu'un script Shell puisse commencer sa vie comme un fichier plus court qu'un script générique équivalent, les surprises conduisent à de nombreux codes d'habillage défensifs, tels que set -euo pipefail pour activer les modes stricts.
Par exemple, la plupart des langages Shell continuent à exécuter des lignes dans un script Shell, même en cas d'échec de l'une des commandes. En revanche, un langage polyvalent échoue immédiatement à la première erreur et souvent de manière très lourde, ce qui entraîne un comportement plus sûr et plus prévisible dans les scripts même de complexité légère.
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 hors du commun, vous aimerez bash.
J'exécute des scripts bash sur des millions de lectures de séquençage d'ADN dans des milliers de fichiers, et cela me convient parfaitement. Et contrairement à ce que tout le monde dit, les mêmes versions des scripts en C++ ne s'exécutent pas beaucoup plus rapidement (séparez-les en quelques minutes).
Je pense que bash, comme Perl, n'est pas le plus convivial/facile à lire. Cela effraie les gens parce que la plupart des gens ne sont pas de grands penseurs abstraits. Mais les programmeurs les plus brillants et les plus créatifs ont tendance à l’aimer et à en faire un usage fréquent. Si vous vous connaissez et savez que vous avez un cerveau, ne soyez pas effrayé par bash. Si vous êtes un penseur de base, gardez peut-être quelque chose comme Python. À chacun ses goûts.
Du "Livre des lamas"
- Randal L. Schwartz, Tom Phoenix et brian d foy,Learning Perl(Sebastopol, CA: O’Reilly, 2011), ch. 1.2 "Que signifie Perl?" , §§ "Pourquoi Larry [le créateur de Perl] n’a-t-il pas utilisé une autre langue?", P. 5:
Perl tente de combler le fossé entre la programmation de bas niveau (telle que C ou C++ ou Assembly) 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 laide, mais rapide et illimitée; difficile de battre la vitesse d’un programme de bas niveau bien écrit sur une machine donnée. Et vous ne pouvez pas faire grand chose 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 si aucune commande sur votre système ne fournit les fonctionnalités nécessaires. Perl est facile, presque illimité, la plupart du temps rapide et un peu moche.