Le terme «coquille» est bien nommé. C'est littéralement un shell autour de l'O / S permettant à l'utilisateur d'interagir avec l'ordinateur. Quand il a été conçu à l'origine, il y avait très peu ou pas d'interfaces utilisateur graphiques (pas de fenêtres :(). Tout a été fait sur la ligne de commande. Mais même la ligne de commande avait besoin d'un endroit pour vivre. Elle vivait, et fait toujours, dans un shell .
En termes simples, pour que la ligne de commande soit utile, elle avait besoin d'instructions qu'elle pouvait appeler. Les programmes ont donc été conçus pour s'exécuter à l'intérieur du shell pour la ligne de commande à utiliser. Les programmes étaient étroitement regroupés dans leurs propres packages et avaient pour objectif de fonctionner ensemble. Ils incluent des programmes comme "ls" et "grep", "ps", "sed", etc. Ils incluent également des commandes de redirection de fichiers comme ">" et "<" et des tuyaux ("|"). Plus important encore, ils incluent également des constructions de programmation comme des opérations conditionnelles (si, alors, sinon, pour les boucles, tandis que les boucles, des moyens de vérifier le statut renvoyé lorsque vous exécutez une instruction (par exemple, si vous exécutez "ls, at-il trouvé quelque chose?), Chose comme ça). Ce sont les fondements de scripts de ligne de commande (shell) plus complexes,
Lorsque quelqu'un utilise le terme «Bash Shell», il s'agit d'un interpréteur de ligne de commande appelé «Bash» qui s'exécute dans le shell O / S. Vous pourriez penser que c'est l'abréviation de «Bash Shell Interpreter». Il existe d'autres interprètes comme Bourne (Bash est un «Bourne Shell nouveau et amélioré et il est l'abréviation de Bourne Again Shell). Il y a aussi le C-Shell, le K-Shell (favorisé par beaucoup de ceux qui écrivent des scripts shell complexes) et d'autres variantes GNU. Au fil des ans, il est devenu habituel de se référer à l'interpréteur de ligne de commande particulier que vous utilisez comme shell, car l'un ne peut pas être utilisé sans l'autre. Mais la réalité est qu'ils sont différents.
Quant à savoir pourquoi ils sont correctement connus en tant qu'interprètes de ligne de commande et non pas comme le shell réel: c'est parce qu'ils vivent dans le shell et interprètent toutes les commandes comme si elles s'exécutaient dans un programme. Et le shell ne se soucie pas de l'interpréteur que vous y exécutez, tant qu'il répond aux normes correctes.
Et pourquoi ils sont appelés interprètes, c'est parce qu'ils sont vraiment des interprètes. Même si vous n'exécutez pas explicitement un script (et qu'un script n'est en fait qu'un fichier texte de commandes que vous créez afin que vous puissiez exécuter les mêmes commandes encore et encore sans avoir à les saisir à nouveau). Par exemple, prenez l'humble commande «ls». Lorsque vous l'exécutez, il renvoie une liste de fichiers. Mais la façon dont il s'exécute est plus importante pour votre question: il s'exécute réellement dans le contexte de l'interpréteur de ligne de commande, même si vous exécutez simplement ce qui semble être une simple commande unique. Autrement dit, il fonctionne comme s'il s'agissait d'une déclaration faisant partie d'un programme plus vaste. Il fonctionne comme s'il se trouvait dans un fichier de script de script shell sans être réellement dans un fichier de script shell. Un fichier de script shell anonyme pour ainsi dire.
Tout ce que vous exécutez sur la ligne de commande a ceci en commun (que ce soit une seule commande comme 'ls' ou un fichier de script rempli de commandes et d'itérateurs et d'instructions conditionnelles): tout est traité par l'interpréteur de ligne de commande; que ce soit Bash, C-Shell, K-Shell (par défaut sur AIX btw).
Pour voir ce que je veux dire, faites un répertoire 'test':
mkdir test
Entrez-le et exécutez les commandes suivantes
grep hello *
Vous obtiendrez une sorte de réponse comme «aucun fichier ou répertoire». Entrez maintenant la commande
echo $?
($? dit, dites-moi ce que vous avez trouvé dans un ordinateur crypté.) Vous devriez le voir retourner un nombre (il devrait être) '2'. C'est le code de retour de grep qui signifie «aucun fichier ou répertoire». Exécutez maintenant ce qui suit:
echo hello > hello.txt
grep hello *
echo $?
Vous verrez le fichier 'hello.txt' renvoyé par la commande grep initiale et vous devriez maintenant voir 'echo $?' renvoie le nombre «0», ce qui signifie qu'il a effectivement trouvé quelque chose.
Même si ces commandes apparemment uniques sont exécutées, l'interpréteur de ligne de commande agit comme si elles faisaient partie d'un programme plus vaste et gardait une trace de leurs valeurs de retour. C'est pourquoi si vous oubliez le * à la fin de la commande grep, il ne revient pas. Il sait que la déclaration est incomplète et attend plus de commentaires. Après tout, vous pourriez peut-être lui demander de récupérer les résultats d'une boucle qui est parfaitement légale pour écrire et s'exécuter sur la ligne de commande.
En fin de compte, le shell est le shell et l'interpréteur (quel que soit le nom de celui que vous utilisez, «Bash», k-shell, etc.) est différent. Mais souvent, ils sont utilisés de manière interchangeable, car à un instant donné, ils sont complètement liés.