Quelle est la différence entre les termes «Shell» et «Bash»?


11

Quelle est la différence entre "Shell" et "Bash" et que signifient ces termes?

Pour autant que je sache, il n'y a pas de différence. Mais j'ai vu de nombreux livres sur "Shell" et d'autres sur "Bash"!

Donc, si je veux travailler avec le terminal sur Mac OS X et écrire des scripts bash, je me demande quel type de livres je devrais choisir.


7
Il s'agit d'une distinction classe / instance.
Kaz

1
Matériel de lecture intéressant: unix.stackexchange.com/questions/4126/…
Bernhard

1
le premier shell a été écrit par un gars appelé Bourne. BASH est un acronyme pour «Boune Again Shell». Il est important de s'amuser!
Kinjal Dixit

Réponses:


31

Un « shell » est un logiciel qui fournit une interface avec un système d'exploitation. Par exemple, explorer.exe est le shell par défaut dans Windows (bien qu'il existe des alternatives ), et sous OS X Finder fournit une grande partie des mêmes fonctionnalités. Sous Linux / * nix, le shell peut faire partie de l'environnement de bureau (comme Gnome ou KDE ), ou peut être un composant logiciel distinct assis dessus (comme Unity ou Cinnamon ).

Les exemples ci-dessus sont tous des shells graphiques qui utilisent une combinaison de fenêtres, menus, icônes et autres éléments de ce type pour fournir une interface utilisateur graphique (GUI) qui peut être interagie avec le curseur de la souris. Cependant, dans le contexte de logiciels comme Bash, ou d'écriture de scripts, "shell" est généralement considéré comme un interpréteur de ligne de commande, qui remplit en grande partie les mêmes fonctions qu'un shell graphique, sauf qu'il est entièrement basé sur du texte.

Bash est un exemple spécifique d'un shell de ligne de commande, et est probablement l'un des plus connus, étant la valeur par défaut dans de nombreuses distributions Linux ainsi que OS X. Il a été conçu en remplacement du shell Bourne (Bash se dresse pour "Bourne again shell"), l'un des premiers shells Unix .

Des exemples de shells de ligne de commande sous Windows incluent cmd.exe (également appelé invite de commande) et PowerShell .


3
Finder n'est généralement pas appelé un shell sur OS X. La plupart des fonctionnalités de gestion de l'interface graphique et des fenêtres sont gérées par d'autres processus.
Lri

1
@LauriRanta Wikipedia semble en désaccord . Qu'il bénéficie ou non de l'aide d'autres processus, son travail consiste à permettre à l'utilisateur d'interagir avec le système d'exploitation sous-jacent via une interface graphique, et correspond ainsi à la description d'un shell graphique.
Indrek

1
Je suppose que le terme shell graphique peut également s'appliquer aux applications de gestion de fichiers. Mais il n'est généralement pas utilisé sur OS X, et Finder ressemble plus à Nautilus qu'au shell Windows ou Unity.
Lri

6
@LauriRanta: quiz rapide, quelle est l'icône de Nautilus?
Lie Ryan

2
@LauriRanta Dock ne serait-il pas un meilleur candidat pour un shell? Le lancement de programmes et l'ouverture de documents, Expose / Spaces / Mission Control, AFAIK Launchpad et le sélecteur de tâches sont également des fonctionnalités du Dock.
Daniel Beck

13

Bash est l'un des nombreux obus.

Un shell sur un système Unix ou Unix comme OSX ou Linux est un programme d'application qui fournit une interface de ligne de commande au système d'exploitation, vous permettant de taper des commandes et de les exécuter. Il existe un certain nombre de shells différents à choisir, mais ils fournissent tous des caractères génériques de nom de fichier, des tuyaux, des documents ici, la substitution de commandes, des variables et des structures de contrôle pour les tests de condition et l'itération.

Le shell Unix original était le shell Bourne , sh, écrit par Stephen Bourne aux Bell Labs. Puis vint le shell C , écrit par Bill Joy à Berkeley, depuis mis à jour en tant que tcsh . D'autres shells incluent le shell Korn , ksh, écrit par David Korn, également aux Bell Labs, et bash , le "Bourne again shell", écrit par Brian Fox pour le projet GNU en remplacement gratuit de sh.

Aujourd'hui, bash est probablement le shell Unix le plus populaire, mais beaucoup de gens (moi y compris) préfèrent toujours le shell C basé sur (ce que certains d'entre nous semblent) sa syntaxe plus agréable. Fondamentalement, c'est une question de goût, donc je vous recommande de lire les articles Wikipedia que j'ai liés pour vous aider à démarrer.


2
Les shells ne sont pas nécessairement basés sur la ligne de commande, il existe également de nombreux shells graphiques, par exemple Nautilus, Windows Explorer, Finder, etc. ie shells assure la gestion des ressources (par exemple la gestion des fichiers) et la gestion des processus.
Lie Ryan

1
@LieRyan ce ne sont pas des coquilles, ce sont des gestionnaires de fichiers. Les shells permettent aux interprètes de commandes / scripts intégrés de s'exécuter en leur sein. Voir ma réponse. Le simple fait d'exécuter un programme à partir d'un gestionnaire de fichiers n'en fait pas un shell.
Bill Rosmus

@BillR: Vous devez informer les gars de Gnome Shell de votre définition.
paradroid

2
Je suis enclin à être d'accord avec Lie Ryan et paradroid, que les coques graphiques sont maintenant considérées comme des coques. Je suis aussi investi dans le paradigme de la ligne de commande que n'importe qui et j'ai résisté à l'acceptation de shells graphiques comme shells dans les années 90. Mais avec tous les widgets du panneau de contrôle et ainsi de suite dans un shell graphique moderne, je suis maintenant d'accord pour dire que l'usage courant est de les appeler shells et que cet usage est correct. Ils correspondent à la définition d'un shell, une couche d'interface utilisateur relativement mince autour du système d'exploitation sous-jacent. Les coquilles graphiques sont plus faibles sur la façon dont quiconque pourrait écrire quoi que ce soit, mais beaucoup d'utilisateurs ne s'en soucient pas.
Nicole Hamilton

6

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.


2

Shell est une interface utilisateur basée sur du texte.

Bash est un type de shell.


2
Qu'est-ce qu'une "interface utilisateur basée sur les tests"? De plus, ce serait bien d'étendre un peu votre réponse. Comme vous pouvez le voir dans les autres réponses, il est toujours utile de donner plus de contexte.
slhck

Pardon. Interface utilisateur textuelle. Comment aimeriez-vous que j'explique cela? Un shell est votre moyen en ligne de commande d'interagir avec le noyau des systèmes d'exploitation. Le Shell interprète vos commandes et les transmet à la machine qui, à son tour, effectue les opérations nécessaires en rapport avec la commande que vous avez donnée? Sans un manuel de 500 pages, il est difficile d'expliquer efficacement cette question ambiguë. L'effort de la réponse correspond à l'effort de la question. Cette question est des pommes aux oranges.
HayekSplosives

Si vous pensez qu'une question montre maintenant un effort qui ne signifie pas automatiquement que vous ne devriez pas y mettre d'effort pour y répondre. Votre réponse, par rapport aux autres, manque un peu de détail. Bien sûr, c'est à vous d'ajouter cela.
slhck

J'apprécie la correction et la leçon de responsabilité personnelle. Merci de protéger ceux qui ne sont pas prêts à faire l'effort de ceux qui le font. Je suis totalement hors de propos en oubliant combien je devais l'affiche.
HayekSplosives


1

bash est l'un des nombreux obus qui existent.

Tous les obus ont leurs similitudes et leurs différences. Par exemple, un script écrit en bash peut être entièrement ou largement compatible avec un autre shell (par exemple zsh ).

En raison du fait qu'il bashest très répandu, il est souvent sous-entendu qu'un script est compatible avec lui.

Si vous cherchez à acheter un livre, achetez-en un écrit spécialement pour la coque que vous souhaitez utiliser. Ce serait une bonne idée de lire leurs différences avant de dépenser de l'argent.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.