Quel est l'avantage du script shell sur les langages de programmation interprétés? [fermé]

(Je ne sais pas si c'est une question appropriée ici)

Les scripts shell, comme ceux écrits en bash, peuvent faire beaucoup de choses. Ils peuvent appeler des programmes Unix, diriger leur sortie, rediriger les E / S de / vers des fichiers, contrôler le flux, vérifier si un fichier existe, etc.

Mais un langage de programmation moderne, par exemple, pythonet ruby, peut également faire ces choses. Et, ils sont (je pense) plus lisibles et maintenables.

bashbénéficie d'une large adoption. Mais de nombreuses distributions ont également installé l' pythoninterpréteur.

Alors, quel est l'avantage de shell un script? Si je pouvais écrire python, rubyou perl, il vaut la peine d'apprendre bash?

Les shells ont des fonctionnalités spécialisées pour travailler avec des fichiers et obtenir des données d'un programme dans un autre (en supposant que les données sont du texte). Pour ces tâches, les scripts shell peuvent être moins lourds qu'un langage de script comme Python.

Les scripts shell ont également l'avantage que les commandes que vous utilisez sont fondamentalement les mêmes commandes que vous utiliseriez à partir de la ligne de commande - donc si vous pouvez faire quelque chose dans le shell, vous êtes à plus de la moitié du script de la même opération.

Voici par exemple un script bash qui déplace tous les fichiers PNG du répertoire courant vers un répertoire spécifié.

#!/usr/bin/sh
mv *.png $1

Voici une version Python.

#!/usr/bin/python
import sys, shutil, glob
for filename in glob.iglob("./*.png"):
    shutil.move(filename, sys.argv[1])

Vous remarquerez:

• Le script bash est un troisième aussi longtemps que le Python si vous comptez les lignes (à l'exclusion de la ligne shebang) - encore moins par nombre de caractères
• Le script Python nécessite l'importation de trois bibliothèques, tandis que tout ce dont vous avez besoin pour cette tâche est nativement disponible dans bash
• Le script Python nécessite une boucle explicite pour déplacer les fichiers, alors que cela fait partie de la sémantique de la mvcommande dans bash
• Le script bash peut s'exécuter plus rapidement - vous l'invoquerez probablement à partir de bash, et vous pouvez l'utiliser sourcepour l'exécuter dans la même instance du shell
• glob.iglob("./*.png") est une bouchée juste pour dire *.png

Si vous vouliez écrire une opération de pipe de base en Python, vous seriez étonné de la verbosité. (Bien sûr, certaines choses, comme le piping grep, peuvent être remplacées par du code Python plutôt que d'utiliser un programme externe, de sorte que vous n'avez souvent pas besoin de canaliser tout autant.)

Comme contre-exemple, j'ai dû écrire une routine qui vérifiait combien de temps chacun des noms de fichiers se trouvait dans un répertoire particulier. S'ils étaient plus longs que ceux pris en charge par un système d'exploitation particulier, ils devaient être raccourcis. Cela pourrait entraîner des noms de fichiers en double, que je devais rectifier, et comme ils seraient liés à partir d'une page Web, les noms raccourcis devaient être stables, c'est-à-dire qu'ils devraient être générés de telle manière que le même nom de fichier long aboutirait toujours à le même nom de fichier raccourci. J'ai fait cela en générant un hexadécimal md5 du nom de fichier long et en ajoutant les quatre premiers caractères de celui-ci au nom abrégé (les noms pouvaient encore entrer en collision, mais c'était très unilatéral, donc j'ai juste vérifié cette condition et j'ai renoncé si cela devait arriver) .

Je l'ai fait en bash car cela faisait partie de notre système de construction qui était déjà écrit en bash. Il était exactement aussi difficile de réussir que vous ne le pensez probablement. Il aurait fallu beaucoup moins de temps pour écrire en Python et aurait probablement été plus clair aussi.

En bref: différentes langues sont conçues pour différents types de tâches; choisissez la langue qui vous convient le mieux pour la tâche à accomplir.

Les réponses existantes sont également valables, mais il y a une raison que personne n'a encore mentionnée: parce qu'elle SERA là.

Toute installation de * nix donnée se fait avec un ensemble de packages optionnels qui peuvent ou non être chargés, et tous les systèmes n'auront pas Python ou Perl ou Ruby. Mais si le système devrait avoir une quelconque capacité interactive, il aura un shell. Cela signifie que les scripts shell fonctionneront sur des systèmes allant des serveurs aux bureaux des programmeurs, en passant par les bureaux des clients légers de secrétariat et les périphériques intégrés, sur tout système prenant en charge un système de fichiers accessible en écriture et une ligne de commande bash.

Pour quelqu'un qui ne travaille que dans un environnement de serveur cohérent, c'est quelque chose qui peut être pris pour acquis, et ce n'est pas si important. Pour quelqu'un qui travaille dans un environnement plus varié, cela ne doit pas être négligé.

Une partie importante de votre question trouve sa réponse ici:

Pourquoi les langages de script (par exemple Perl, Python, Ruby) ne conviennent-ils pas comme langages shell?

Voici un extrait de ma réponse à cette question :

Il y a quelques différences auxquelles je peux penser; juste en train de réfléchir ici, sans ordre particulier:

1. Python & Co. sont conçus pour être bons en scripting. Bash & Co. est conçu pour être uniquement bon en script, sans aucun compromis. IOW: Python est conçu pour être bon à la fois en script et en non-script, Bash ne se soucie que des scripts.

2. Bash & Co. ne sont pas typés, Python & Co. sont fortement typés, ce qui signifie que le nombre 123, la chaîne 123et le fichier 123sont assez différents. Cependant, ils ne sont pas typés statiquement , ce qui signifie qu'ils doivent avoir des littéraux différents pour ceux-ci, afin de les séparer. Exemple:

   • Rubis: 123(nombre), Bash:123
   • Ruby: '123'(chaîne), Bash:123
   • Ruby: /123/(regexp), Bash:123
   • Ruby: File.open('123')(fichier), Bash:123
   • Ruby: IO.open('123')(descripteur de fichier), Bash:123
   • Ruby: URI.parse('123')(URI), Bash:123
   • Ruby: `123`(commande), Bash:123

3. Python & Co. sont conçus pour évoluer jusqu'à 10000, 100000, peut-être même 1000000 programmes de ligne, Bash & Co. sont conçus pour réduire à 10 programmes de caractères .

4. Dans Bash & Co., les fichiers, les répertoires, les descripteurs de fichiers, les processus sont tous des objets de première classe, en Python, seuls les objets Python sont de première classe, si vous voulez manipuler des fichiers, des répertoires, etc., vous devez les encapsuler dans un Objet Python en premier.

5. La programmation shell est essentiellement une programmation de flux de données. Personne ne s'en rend compte, pas même les personnes qui écrivent des shells, mais il s'avère que les shells sont assez bons dans ce domaine, et les langages à usage général pas tellement. Dans le monde de la programmation à usage général, le flux de données semble être principalement considéré comme un modèle de concurrence, pas tant qu'un paradigme de programmation.

J'ai le sentiment qu'essayer de résoudre ces points en boulonnant des fonctionnalités ou des DSL sur un langage de programmation à usage général ne fonctionne pas. Au moins, je n'ai pas encore vu une mise en œuvre convaincante de celui-ci. Il y a RuSH (Ruby shell), qui essaie d'implémenter un shell dans Ruby, il y a rush, qui est un DSL interne pour la programmation de shell dans Ruby, il y a Hotwire, qui est un shell Python, mais IMO aucun de ceux-ci ne vient même près pour rivaliser avec Bash, Zsh, fish et amis.

Je dirais qu'un script shell a l'avantage dans les situations où vous voulez simplement concocter une tâche automatisée super simple. Par exemple, si vous vouliez écrire un script qui sauvegarde un répertoire d'un serveur à un autre tous les jours à 5h00, il serait exagéré d'utiliser un langage de programmation robuste.

D'un autre côté, si votre tâche de programmation a plus besoin de structures de contrôle (if / then / else), de structures itératives (bouclage), d'E / S de base de données et de fichiers, etc., alors elle est probablement mieux adaptée à un système plus performant. langage de programmation qu'un script shell.

Je pense qu'une bonne règle d'or est la suivante:

automatingSimpleTask ? shellScript() : programmingLanguage();

Bien que vous puissiez lancer des programmes à partir d'un programme python / ruby ​​/ peu importe, c'est différent dans le shell. Vous devrez peut-être utiliser une API pour lancer quelque chose - fork () par exemple. Dans un script shell, les programmes se comportent plus comme des fonctions dans un langage de programmation conventionnel et peuvent être exécutés, canalisés, etc. avec un minimum d'effort. Le flux de données est également très clair en utilisant des tuyaux.

Si vous êtes totalement libre de choisir le langage de programmation que vous utilisez pour certaines tâches, vous pourriez probablement éviter presque complètement d'apprendre bash et effectuer toutes les tâches de programmation de script avec Perl, Python ou Ruby. Cela peut parfois conduire à une solution plus détaillée, en particulier dans le cas où vous avez juste besoin d'un script appelant une séquence d'autres outils Unix, mais dans des cas plus complexes, vous avez raison, ces langages de script modernes vous offrent plus de possibilités pour écrire un code mieux maintenable (ils vous donnent également plus de possibilités d'écrire du code obscurci, mais c'est votre choix).

D'un autre côté, nous ne sommes souvent pas libres de choisir la langue que nous aimons le plus, car nous devons travailler avec du code hérité ou du code écrit par quelqu'un qui connaissait bash mais ne connaissait pas l'un des langages de script que vous avez nommés.

Les scripts shell sont un langage de programmation interprété. Voici quelques raisons pour lesquelles j'ai choisi d'écrire des scripts en bash au lieu de perl ou python ou d'un autre langage de script:

Fonctionne partout : des interprètes plus complexes peuvent ne pas toujours être disponibles, comme lors du démarrage du système ou sur des systèmes embarqués. Bash est disponible même dans busybox.

Fonctionne sur la ligne de commande : si vous connaissez bien les scripts shell, vous pouvez utiliser ces compétences pour faire des choses complexes dans des scripts ad hoc directement sur la ligne de commande. J'utilise cette compétence quotidiennement en tant qu'administrateur système.

Plus facile à écrire des programmes qui appellent d'autres programmes: si ce que vous essayez de faire est de chaîner plusieurs programmes existants de façon intéressante, il peut être plus simple de le faire dans un script shell qu'avec un langage de niveau supérieur.

Si le programme est de 30 lignes ou moins, je l'écrirai généralement en utilisant un script shell. S'il y a une manipulation complexe ou complexe ou une analyse à gérer, je le ferai en utilisant python ou perl.

Vous devriez jeter un œil à coffeescript. Leurs mots:

Sous tous ces accolades et points-virgules maladroits, JavaScript a toujours eu un magnifique modèle d'objet en son cœur. CoffeeScript est une tentative d'exposer les bonnes parties de JavaScript d'une manière simple.

La règle d'or de CoffeeScript est: "C'est juste du JavaScript".

Eh bien ... voici la réponse du super-débutant.

En tant que débutant en auto-apprentissage depuis 6 mois, et en dégustant un peu de C, C ++, Javascript, et plus de Bashscript ces derniers jours ... je peux vous dire:

Les scripts shell, comme ceux écrits en bash, peuvent faire beaucoup de choses. Ils peuvent appeler des programmes Unix, diriger leur sortie, rediriger les E / S de / vers des fichiers, contrôler le flux, vérifier si un fichier existe, etc.

et ce n'est pas si simple que ça ! ? boucles et variables? Hou la la!

python et rubis, peuvent également faire ces choses. Et, ils sont (je pense) plus lisibles et maintenables.

S'il vous plaît, dites-moi où vous voyez cela? J'ai écrit bashscript dans gedit même dans geany et je peux formater, (tabs?) Et j'ai lu mon code à la vitesse de la lumière en utilisant bashscript en comparaison avec d'autres langues.

Ces langues ont-elles d'autres outils pour maintenir l'ordre? Je sais que la gestion orientée objet enregistre BEAUCOUP de code, mais ... les gens disent que bashscript est aussi OO! WOW 2! C'est mon point ici. Aller à:

l'avantage de shell un script

est à l'intérieur de cette question: comment faire ce que ce bashdamnthing peut faire en perl ou en phyton ou en rubis? C'est facile?

( bashdamnthing = xdotool )