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

Question

Quelles sont les différences entre les langages shell comme bash , zsh , poisson et les langages de script ci-dessus qui les rendent plus adaptés à l'interpréteur de commandes ?

Lorsqu'on utilise la ligne de commande, les langages shell semblent beaucoup plus faciles. Il me semble beaucoup plus facile d'utiliser bash par exemple que d'utiliser le profil shell dans ipython, malgré les rapports qui disent le contraire . Je pense que la plupart des gens seront d'accord avec moi pour dire qu'une grande partie de la programmation à moyenne et grande échelle est plus facile en Python qu'en bash. J'utilise Python comme le langage avec lequel je suis le plus familier, il en va de même pour Perl et Ruby.

J'ai essayé d'en expliquer la raison, mais je n'y suis pas parvenu, si ce n'est en supposant que le traitement différent des cordes dans les deux cas y est pour quelque chose.

La raison de cette question est que j'espère développer un langage utilisable dans les deux. Si vous connaissez un tel langage, merci de le poster également.

Comme l'explique S.Lott, la question doit être clarifiée. Je m'interroge sur les caractéristiques de l'obus langue par rapport à celle des langages de script. La comparaison ne porte donc pas sur les caractéristiques des différents langages interactifs ( REPL ) tels que l'historique et la substitution de ligne de commande. Une expression alternative pour la question serait :

Un langage de programmation qui convient à la conception de systèmes complexes peut-il en même temps être capable d'exprimer des lignes uniques utiles qui peuvent accéder au système de fichiers ou contrôler des travaux ? Un langage de programmation peut-il utilement évoluer vers le haut comme vers le bas ?

Answer 1

Ce fil de discussion m'a incité à prendre en charge la maintenance du shell Zoidberg basé sur Perl. Après quelques corrections, il est à nouveau utilisable ! Allez voir le guide de l'utilisateur ou installer Bundle::Zoidberg en utilisant votre client CPAN préféré.

Answer 2

Non.

---

Non, les langages de script ne sont probablement pas adaptés aux shells.

---

Le problème est la dichotomie entre langages macro et, bien, tout le reste.

L'interpréteur de commandes est dans une catégorie avec d'autres anciens langages macro tels que nroff y m4 . Dans ces processeurs, tout est une chaîne et le processeur définit une correspondance entre les chaînes d'entrée et les chaînes de sortie.

Certaines limites sont franchies dans les deux sens dans toutes les langues, mais il est généralement assez clair si la catégorie d'un système est macro ou, hmm, je ne connais pas de terme officiel ... Je dirai "une vraie langue".

Alors bien sûr, vous pourrait Tapez toutes vos commandes dans un langage comme Ruby, et il pourrait même être un second choix par rapport à un vrai shell, mais il ne sera jamais un langage macro. Il y a trop de syntaxe à respecter. Il y a trop de guillemets.

Mais le langage macro a ses propres problèmes lorsque vous commencez à programmer dedans, car trop de compromis ont dû être faits pour se débarrasser de toute cette syntaxe. Les chaînes de caractères sont saisies sans guillemets. Des quantités diverses de magie doivent être réintroduites pour injecter la syntaxe manquante. J'ai fait un code-golf dans Nroff une fois, juste pour être différent. C'était assez étrange. Le code source des grandes implémentations dans les langages macro est effrayant.

Answer 3

Je pense que c'est une question d'analyse. Les langages shell supposent par défaut que $ command signifie que vous voulez lancer une commande, Python/Ruby ont besoin que vous fassiez system("command") ou autre. Ce n'est pas qu'ils sont inadaptés, c'est juste que personne ne l'a encore fait, du moins je le pense. Rush http://rush.heroku.com/ est un exemple de tentative en Ruby, Python a "iPython" ou quelque chose comme ça.

Answer 4

Comme il s'agit de deux langages de programmation formels, ce que vous pouvez faire dans l'un, vous pouvez le faire dans l'autre. En fait, il s'agit d'une question d'accentuation de la conception. Les langages shell sont conçus pour une utilisation interactive, alors que les langages de script ne le sont pas.

La différence fondamentale dans la conception est le stockage des données entre les commandes et la portée des variables. En Bash, etc., vous devez sauter par-dessus des cerceaux pour stocker une valeur (par exemple, des commandes comme set a='something' ), tandis que dans des langages comme Python, vous utilisez simplement une instruction d'affectation ( a = 'something' ). Lorsque vous utilisez les valeurs dans un langage shell, vous devez indiquer au langage que vous voulez la valeur de la variable, tandis que dans les langages de script, vous devez indiquer au langage que vous voulez la valeur immédiate de la chaîne. Cela a des effets lorsqu'on l'utilise de manière interactive.

Dans un langage de script où ls a été défini comme une commande

a = some_value

ls a*b  

(Qu'est-ce que a C'est-à-dire ? Est-ce que cela signifie some_value * (quelle que soit la valeur de b) ou est-ce que vous voulez dire 'a'anystring'b' ?. Dans un langage de script, la valeur par défaut est ce qui est stocké en mémoire pour a).

ls 'a*b'  Now means what the Unix ls a*b means.

Dans un langage de type Bash

set a=some_value

ls a*b   means what the Unix ls a*b means.

ls $a*b  uses an explicit recall of the value of a.

Les langages de script facilitent le stockage et le rappel des valeurs et rendent difficile l'application transitoire d'une valeur. Les langages shell permettent de stocker et de rappeler des valeurs, mais ont une portée trivialement transitoire par commande.

Answer 5

Évolutivité et extensibilité ? Common Lisp (vous pouvez même exécuter CLISP, et éventuellement d'autres implémentations, comme un shell de connexion dans les environnements UNIX).