Différence entre sh et bash


1305

Lors de l'écriture de programmes shell, nous utilisons souvent /bin/shet /bin/bash. J'utilise habituellement bash, mais je ne sais pas quelle est la différence entre eux.

Quelle est la principale différence entre bashet sh?

Que devons-nous savoir lors de la programmation dans bashet sh?


21
Pour une liste utile des bashismes et du code correspondant qui fonctionne sur le shell Bourne, voir mywiki.wooledge.org/Bashism
StackExchange saddens dancek

1
Vous voudrez peut-être voir la norme POSIX pour sh et son langage de commande: * sh * Langage de commande shell
Maurício C Antunes

7
en règle générale, tous les scripts sh s'exécuteront sous bash grâce à sa compatibilité posix, mais tous les scripts bash ne peuvent pas s'exécuter sous sh, les principales différences que vous remarquez sont des choses comme [[]] au lieu de [] des comparaisons qui autorisent les espaces sans guillemets, $ (()) au lieu d'expressions arithmétiques $ [], et d'autres choses comme "c'est trop gros et trop lent" directement à partir des documents bash .. Mais les nouveaux scripteurs n'ont pas besoin de se limiter à des scripts compatibles sh à moins qu'ils ne tournent pour certains rétrocompatibilité, ce qui n'est pas le cas le plus souvent de nos jours, après tout c'est (ou était ...) l'année 2014 à droite ??
osirisgothra

Réponses:


1142

Quel est sh

sh(ou Shell Command Language) est un langage de programmation décrit par la norme POSIX . Il a de nombreuses implémentations ( ksh88, dash, ...). bashpeut également être considérée comme une implémentation de sh(voir ci-dessous).

Parce que shc'est une spécification, pas une implémentation, /bin/shest un lien symbolique (ou un lien dur) vers une implémentation réelle sur la plupart des systèmes POSIX.

Qu'est-ce que bash

basha commencé comme une shimplémentation compatible (bien qu'elle soit antérieure au standard POSIX de quelques années), mais avec le temps, elle a acquis de nombreuses extensions. Beaucoup de ces extensions peuvent changer le comportement des scripts shell POSIX valides, donc en soi bashn'est pas un shell POSIX valide. Il s'agit plutôt d'un dialecte du langage shell POSIX.

bashprend en charge un --posixcommutateur, ce qui le rend plus conforme à POSIX. Il essaie également d'imiter POSIX s'il est appelé en tant que sh.

sh = bash?

Pendant longtemps, /bin/shutilisé pour pointer /bin/bashsur la plupart des systèmes GNU / Linux. En conséquence, il était presque devenu sûr d'ignorer la différence entre les deux. Mais cela a commencé à changer récemment.

Voici quelques exemples populaires de systèmes sur lesquels /bin/shne pointe pas /bin/bash(et sur certains d'entre eux qui /bin/bashn'existent même pas):

  1. Les systèmes Debian et Ubuntu modernes, qui ont un lien symbolique shvers dashpar défaut;
  2. Busybox , qui est généralement exécuté pendant le démarrage du système Linux dans le cadre de initramfs. Il utilise l' ashimplémentation du shell.
  3. BSD, et en général tous les systèmes non Linux. OpenBSD utilise pdksh, un descendant du shell Korn. FreeBSD shest un descendant du shell UNIX Bourne d'origine. Solaris a la sienne shqui, pendant longtemps, n'était pas compatible POSIX; une implémentation gratuite est disponible à partir du projet Heirloom .

Comment pouvez-vous savoir ce qui /bin/shpointe sur votre système?

La complication est que cela /bin/shpourrait être un lien symbolique ou un lien dur. S'il s'agit d'un lien symbolique, un moyen portable de le résoudre est:

% file -h /bin/sh
/bin/sh: symbolic link to bash

Si c'est un lien dur, essayez

% find -L /bin -samefile /bin/sh
/bin/sh
/bin/bash

En fait, le -Ldrapeau couvre à la fois les liens symboliques et les liens durs, mais l'inconvénient de cette méthode est qu'elle n'est pas portable - POSIX n'a pas besoin find de prendre en charge l' -samefileoption, bien que GNU find et FreeBSD find la prennent en charge.

Ligne Shebang

En fin de compte, c'est à vous de décider laquelle utiliser, en écrivant la ligne «shebang» comme toute première ligne du script.

Par exemple

#!/bin/sh

utilisera sh(et quoi que ce soit qui pointe),

#!/bin/bash

utilisera /bin/bashs'il est disponible (et échouera avec un message d'erreur s'il ne l'est pas). Bien sûr, vous pouvez également spécifier une autre implémentation, par exemple

#!/bin/dash

Lequel utiliser

Pour mes propres scripts, je préfère shpour les raisons suivantes:

  • il est standardisé
  • c'est beaucoup plus simple et plus facile à apprendre
  • il est portable sur tous les systèmes POSIX - même s’ils n’en ont pas bash, ils doivent avoirsh

Il y a aussi des avantages à utiliser bash. Ses fonctionnalités rendent la programmation plus pratique et similaire à la programmation dans d'autres langages de programmation modernes. Ceux-ci incluent des éléments tels que des variables et des tableaux locaux étendus. Plain shest un langage de programmation très minimaliste.


Si vous exécutez un script avec bashla manière d'affichage des messages d'erreur plus utiles en cas d'erreur de syntaxe. Vous pouvez simplement gagner du temps en utilisant bash.
PHPst

Que %signifie au début de vos lignes de commande?
JosephHarriott

@JosephHarriott c'est une invite: un caractère imprimé par le shell lui-même après quoi votre commande suit. Certains shells utilisent à la $place de %, ou #pour le shell racine.
Roman Cheplyaka

@RomanCheplyaka quels obus? Je n'ai jamais vu $et #...
JosephHarriott

@RomanCheplyaka Je suis certain qu'il shexistait bien avant bash (qui signifie bourne-again shell). Mais c'était très primitif et ne répondait pas aux événements terminaux, comme les ESCpersonnages. Puis kshest venu (également avant bash), puis bash a commencé par ceux qui aimaient l'idée d'un meilleur shell, mais détestaient ksh. :-)
raminr

145

sh: http://man.cx/sh
bash : http://man.cx/bash

TL; DR : bashest un sur-ensemble de shavec une syntaxe plus élégante et plus de fonctionnalités. Il est sûr d'utiliser une ligne bash shebang dans presque tous les cas car elle est assez omniprésente sur les plates-formes modernes.

NB: dans certains environnements, sh c'est bash . Vérifiez sh --version.


31
si bash est invoqué comme sh, il se comporte un peu différemment. Voir gnu.org/software/bash/manual/bashref.html#Bash-Startup-Files ("Appelé avec le nom sh") et gnu.org/software/bash/manual/bashref.html#Bash-POSIX-Mode . Par exemple, aucune substitution de processus.
glenn jackman

11
Comme bash est un surensemble de sh et que certains OS comme FreeBSD n'ont pas bash installé par défaut, les scripts dans sh donneront une plus grande portabilité.
user674062

1
Comme il n'existe aucun moyen scriptable portable pour obtenir un shell POSIX pour un script spécifique, les scripts portables ne peuvent pas assumer plus de fonctionnalités que Bourne Shell.
schily

83

Cette question a souvent été désignée comme canonique pour les personnes qui essaient d'utiliser shet sont surpris qu'elle ne se comporte pas de la même manière que bash. Voici un bref aperçu des malentendus et des pièges courants.

Tout d'abord, vous devez savoir à quoi vous attendre.

  • Si vous exécutez votre script avec sh scriptname, ou exécutez-le avec scriptnameet avez #!/bin/shdans la ligne shebang , vous devez vous attendre à un shcomportement POSIX .
  • Si vous exécutez votre script avec bash scriptname, ou l'exécutez avec scriptnameet avez #!/bin/bash(ou l'équivalent local) dans la ligne shebang, vous devez vous attendre à un comportement Bash.

Avoir un shebang correct et exécuter le script en tapant juste le nom du script (éventuellement avec un chemin relatif ou complet ) est généralement la solution préférée. En plus d'un shebang correct, cela nécessite que le fichier de script ait la permission d'exécution ( chmod a+x scriptname).

Alors, comment diffèrent-ils réellement?

Le manuel de référence Bash contient une section qui tente d'énumérer les différences, mais certaines sources courantes de confusion incluent

  • [[n'est pas disponible en sh(seulement [ce qui est plus maladroit et limité).
  • sh n'a pas de tableaux.
  • Certains mots clés Bash aiment local, source, function, shopt, let, declareet selectne sont pas portables sh. (Certaines shimplémentations prennent en charge par exemple local.)
  • Bash a de nombreuses extensions de syntaxe C de style comme les trois arguments en for((i=0;i<=3;i++))boucle, +=affectation incrément, etc. La $'string\nwith\tC\aescapes'fonction est provisoirement acceptée pour POSIX ( ce qui signifie qu'il fonctionne dans Bash maintenant, mais pas encore être pris en charge par shles systèmes qui adhèrent seulement au courant Spécification POSIX, et ne le sera probablement pas avant un certain temps).
  • Bash prend en charge <<<'here strings'.
  • Bash a *.{png,jpg}et {0..12}accroît l'expansion.
  • ~se réfère $HOMEuniquement à Bash (et plus généralement ~usernameau répertoire personnel de username).C'est dans POSIX, mais peut être absent de certaines /bin/shimplémentations pré-POSIX .
  • Bash a une substitution de processus avec <(cmd)et >(cmd).
  • Bash a des alias de redirection de commodité de style Csh comme &|pour 2>&1 |et &>pour> ... 2>&1
  • Bash prend en charge les coprocessus avec <>redirection.
  • Bash dispose d' un riche ensemble d'extensions de paramètres non standard étendus tels que ${substring:1:2}, la ${variable/pattern/replacement}conversion de cas, etc.
  • Bash a considérablement étendu les fonctionnalités d'arithmétique des coques (bien qu'il n'y ait toujours pas de support en virgule flottante). Il existe une $[expression]syntaxe héritée obsolète qui doit cependant être remplacée par une $((expression))syntaxe arithmétique POSIX . (Certaines shimplémentations pré-POSIX héritées peuvent ne pas prendre en charge cela, cependant.)
  • Les variables magiques comme $RANDOM, $SECONDS, $PIPESTATUS[@]et $FUNCNAMEsont des extensions Bash.
  • Différences syntaxiques comme export variable=valueet [ "x" == "y" ]qui ne sont pas portables ( export variabledoivent être séparées de l'affectation des variables, et la comparaison de chaînes portable [ ... ]utilise un seul signe égal).
  • De nombreuses extensions Bash uniquement pour activer ou désactiver le comportement facultatif et exposer l'état interne du shell.
  • De nombreuses fonctionnalités pratiques pour une utilisation interactive qui n'affectent cependant pas le comportement du script.

N'oubliez pas qu'il s'agit d'une liste abrégée. Reportez-vous au manuel de référence pour le scoop complet, et http://mywiki.wooledge.org/Bashism pour de nombreuses bonnes solutions de contournement; et / ou essayez http://shellcheck.net/ qui met en garde contre de nombreuses fonctionnalités Bash uniquement.

Une erreur courante consiste à avoir une #!/bin/bashligne shebang, mais à utiliser néanmoins sh scriptnamepour exécuter réellement le script. Cela désactive essentiellement toute fonctionnalité Bash uniquement, vous obtenez donc des erreurs de syntaxe, par exemple pour essayer d'utiliser des tableaux. (La ligne shebang est syntaxiquement un commentaire, elle est donc simplement ignorée dans ce scénario.)

Malheureusement, Bash ne vous avertit pas lorsque vous essayez d'utiliser ces constructions lorsqu'il est invoqué en tant que sh. Il ne désactive pas non plus complètement toutes les fonctionnalités de Bash uniquement, donc exécuter Bash en l'invoquant shn'est pas un bon moyen de vérifier si votre script est correctement portable sur ash/ dash/ POSIX shou des variantes comme Heirloomsh


2
Fondamentalement, la version TL; DR est la réponse de And .
tripleee

4
shellcheck.net était tout ce dont j'avais besoin. Merci beaucoup.
Josh Habdas

FWIW, export variable=valueest mandaté par POSIX: pubs.opengroup.org/onlinepubs/009695399/utilities/export.html . Peut-être que ce n'est pas disponible dans certains coquillages anciens, mais ce n'est certainement pas un bashisme.
Roman Cheplyaka

54

Shell est une interface entre un utilisateur et le système d'exploitation pour accéder aux services d'un système d'exploitation. Il peut s'agir d'une interface graphique ou d'une interface de ligne de commande (CLI).

sh (Bourne sh ell) est un interpréteur de ligne de commande shell, pour les systèmes d'exploitation Unix / Unix. Il fournit des commandes intégrées. Dans le langage de script, nous désignons l'interpréteur comme #!/bin/sh. Il était l'un des plus largement pris en charge par d'autres shells comme bash (gratuit / ouvert), kash (non gratuit).

Bash ( B ourne a gain s hell) est un remplacement de shell pour le shell Bourne. Bash est un surensemble de sh. Bash prend en charge sh. POSIX est un ensemble de normes définissant le fonctionnement des systèmes compatibles POSIX. Bash n'est pas en fait un shell compatible POSIX. Dans un langage de script, nous désignons l'interpréteur comme #!/bin/bash.

Analogie:

  • Shell est comme une interface ou des spécifications ou une API.
  • sh est une classe qui implémente l'interface Shell.
  • Bash est une sous-classe du sh.

entrez la description de l'image ici


3
Je ne comprends pas. Vous avez mentionné à la fois "Bash est un surensemble de sh" et "Bash est une sous-classe de sh", n'est-ce pas des déclarations contraires? Pouvez-vous clarifier s'il vous plait?
Keerthana Prabhakaran

11
Je pense que cela essaie de dire que Bash hérite de sh(c'est donc une "sous-classe" au sens de la POO) et l'étend (donc a un surensemble de la fonctionnalité).
tripleee

53

Message d' UNIX.COM

Caractéristiques du shell

Ce tableau ci-dessous répertorie la plupart des fonctionnalités qui, je pense, vous inciteraient à choisir un shell plutôt qu'un autre. Il n'est pas destiné à être une liste définitive et n'inclut pas toutes les fonctionnalités possibles pour chaque shell possible. Une fonctionnalité n'est considérée comme étant dans un shell que dans la version fournie avec le système d'exploitation, ou si elle est disponible telle que compilée directement à partir de la distribution standard. En particulier, le shell C spécifié ci-dessous est celui disponible sur SUNOS 4. *, un nombre considérable de fournisseurs expédient désormais soit tcsh soit leur propre shell C amélioré à la place (ils ne rendent pas toujours évident qu'ils expédient tcsh.

Code:

                                     sh   csh  ksh  bash tcsh zsh  rc   es
Job control                          N    Y    Y    Y    Y    Y    N    N
Aliases                              N    Y    Y    Y    Y    Y    N    N
Shell functions                      Y(1) N    Y    Y    N    Y    Y    Y
"Sensible" Input/Output redirection  Y    N    Y    Y    N    Y    Y    Y
Directory stack                      N    Y    Y    Y    Y    Y    F    F
Command history                      N    Y    Y    Y    Y    Y    L    L
Command line editing                 N    N    Y    Y    Y    Y    L    L
Vi Command line editing              N    N    Y    Y    Y(3) Y    L    L
Emacs Command line editing           N    N    Y    Y    Y    Y    L    L
Rebindable Command line editing      N    N    N    Y    Y    Y    L    L
User name look up                    N    Y    Y    Y    Y    Y    L    L
Login/Logout watching                N    N    N    N    Y    Y    F    F
Filename completion                  N    Y(1) Y    Y    Y    Y    L    L
Username completion                  N    Y(2) Y    Y    Y    Y    L    L
Hostname completion                  N    Y(2) Y    Y    Y    Y    L    L
History completion                   N    N    N    Y    Y    Y    L    L
Fully programmable Completion        N    N    N    N    Y    Y    N    N
Mh Mailbox completion                N    N    N    N(4) N(6) N(6) N    N
Co Processes                         N    N    Y    N    N    Y    N    N
Builtin artithmetic evaluation       N    Y    Y    Y    Y    Y    N    N
Can follow symbolic links invisibly  N    N    Y    Y    Y    Y    N    N
Periodic command execution           N    N    N    N    Y    Y    N    N
Custom Prompt (easily)               N    N    Y    Y    Y    Y    Y    Y
Sun Keyboard Hack                    N    N    N    N    N    Y    N    N
Spelling Correction                  N    N    N    N    Y    Y    N    N
Process Substitution                 N    N    N    Y(2) N    Y    Y    Y
Underlying Syntax                    sh   csh  sh   sh   csh  sh   rc   rc
Freely Available                     N    N    N(5) Y    Y    Y    Y    Y
Checks Mailbox                       N    Y    Y    Y    Y    Y    F    F
Tty Sanity Checking                  N    N    N    N    Y    Y    N    N
Can cope with large argument lists   Y    N    Y    Y    Y    Y    Y    Y
Has non-interactive startup file     N    Y    Y(7) Y(7) Y    Y    N    N
Has non-login startup file           N    Y    Y(7) Y    Y    Y    N    N
Can avoid user startup files         N    Y    N    Y    N    Y    Y    Y
Can specify startup file             N    N    Y    Y    N    N    N    N
Low level command redefinition       N    N    N    N    N    N    N    Y
Has anonymous functions              N    N    N    N    N    N    Y    Y
List Variables                       N    Y    Y    N    Y    Y    Y    Y
Full signal trap handling            Y    N    Y    Y    N    Y    Y    Y
File no clobber ability              N    Y    Y    Y    Y    Y    N    F
Local variables                      N    N    Y    Y    N    Y    Y    Y
Lexically scoped variables           N    N    N    N    N    N    N    Y
Exceptions                           N    N    N    N    N    N    N    Y

Clé du tableau ci-dessus.

La fonctionnalité Y peut être effectuée à l'aide de ce shell.

N La fonctionnalité n'est pas présente dans le shell.

F La fonctionnalité ne peut être effectuée qu'en utilisant le mécanisme de fonction des coques.

L La bibliothèque readline doit être liée au shell pour activer cette fonctionnalité.

Remarques sur le tableau ci-dessus

1. This feature was not in the original version, but has since become
   almost standard.
2. This feature is fairly new and so is often not found on many
   versions of the shell, it is gradually making its way into
   standard distribution.
3. The Vi emulation of this shell is thought by many to be
   incomplete.
4. This feature is not standard but unofficial patches exist to
   perform this.
5. A version called 'pdksh' is freely available, but does not have
   the full functionality of the AT&T version.
6. This can be done via the shells programmable completion mechanism.
7. Only by specifying a file via the ENV environment variable.

Votre table ne m'est pas utile car elle essaie de comparer les fonctionnalités du Bourne Shell et les fonctionnalités de ksh d'avant 1988. Si vous créez vraiment une table pour 1988, vous devrez supprimer la plupart des autres shells de cette table - y compris bash , sh et rc. Pourriez-vous expliquer d'où avez-vous obtenu les valeurs de votre table?
schily

1
Permettez-moi de donner quelques conseils: Job Control a été ajouté au Bourne Shell en 1989 et le Bourne Shell a été créé OpenSource en 2005. Le shell Korn a une substitution de processus depuis au moins 1988 et il est OpenSource depuis 1997. BTW: vos déclarations concernant $ ENV ne sont pas corrects, $ ENV n'est lu / exécuté que pour les shells interactifs.
schily


@schily Si vous pensez que c'est incorrect quelque part, n'hésitez pas à le modifier de manière appropriée.
SriniV

8
Sur la base de ce que Schily a exposé, il semblerait qu'il serait préférable de supprimer cette réponse, car elle est essentiellement frauduleuse, et OP n'a pas vraiment vérifié les informations qu'il a collées.
danno

24

TERMINAL

  • programme (s) qui ouvre une fenêtre
  • xterm, rxvt, konsole, kvt, gnome-terminal, nxterm et eterm.

COQUILLE

  • Est un programme qui s'exécute dans le terminal
  • Shell est à la fois un interpréteur de commandes et un langage de programmation
  • Shell est simplement un macro processeur qui exécute des commandes.
  • Macro processeur signifie une fonctionnalité où le texte et les symboles sont développés pour créer des expressions plus grandes.

SH Vs. FRAPPER

SH

  • (Coquille)
  • Est un shell spécifique
  • un interpréteur de commandes et un langage de programmation
  • Prédécesseur de BASH

FRAPPER

  • (Coquille Bourne-Again)
  • Est un shell spécifique
  • un interpréteur de commandes et un langage de programmation
  • Possède une fonctionnalité sh et plus
  • Successeur de SH
  • BASH est le SHELL par défaut

MATÉRIEL DE RÉFÉRENCE:

COQUILLE gnu.org:

À sa base, un shell est simplement un macro processeur qui exécute des commandes. Le terme macro processeur signifie fonctionnalité où le texte et les symboles sont développés pour créer des expressions plus grandes.

Un Unix shell est à la fois un interpréteur de commandes et un langage de programmation. En tant qu'interpréteur de commandes, le shell fournit l'interface utilisateur à l'ensemble riche des utilitaires GNU. Les fonctionnalités du langage de programmation permettent de combiner ces utilitaires. Les fichiers contenant des commandes peuvent être créés et devenir des commandes eux-mêmes. Ces nouvelles commandes ont le même statut que les commandes système dans des répertoires tels que / bin, permettant aux utilisateurs ou aux groupes d'établir des environnements personnalisés pour automatiser leurs tâches courantes.

Les coques peuvent être utilisées de manière interactive ou non interactive. En mode interactif, ils acceptent les entrées saisies au clavier. Lors de l'exécution de manière non interactive, les shells exécutent des commandes lues dans un fichier.

Un shell permet l'exécution de commandes GNU, de manière synchrone et asynchrone. Le shell attend la fin des commandes synchrones avant d'accepter plus de saisie; les commandes asynchrones continuent de s'exécuter en parallèle avec le shell pendant qu'il lit et exécute des commandes supplémentaires. Les constructions de redirection permettent un contrôle précis de l'entrée et de la sortie de ces commandes. De plus, le shell permet de contrôler le contenu des environnements de commandes.

Les shells fournissent également un petit ensemble de commandes intégrées (intégrées) mettant en œuvre des fonctionnalités impossibles ou peu pratiques à obtenir via des utilitaires distincts . Par exemple, cd, break, continue et exec ne peuvent pas être implémentés en dehors du shell car ils manipulent directement le shell lui-même. L'historique, getopts, kill ou pwd, entre autres, pourraient être implémentés dans des utilitaires distincts, mais ils sont plus pratiques à utiliser comme commandes intégrées. Toutes les commandes internes du shell sont décrites dans les sections suivantes.

Bien que l'exécution de commandes soit essentielle, la majeure partie (et la complexité) des shells est due à leurs langages de programmation intégrés. Comme tout langage de haut niveau, le shell fournit des variables, des constructions de contrôle de flux, des citations et des fonctions.

Les shells offrent des fonctionnalités spécialement conçues pour une utilisation interactive plutôt que pour augmenter le langage de programmation. Ces fonctionnalités interactives incluent le contrôle des travaux, la modification de la ligne de commande, l'historique des commandes et les alias. Chacune de ces fonctionnalités est décrite dans ce manuel.

BASH gnu.org:

Bash est le shell, ou interpréteur de langage de commande, pour le système d'exploitation GNU. Le nom est l'acronyme de `` Bourne-Again SHell '', un jeu de mots sur Stephen Bourne, l'auteur de l'ancêtre direct de l'actuel shell sh Unix, qui est apparu dans la septième édition de la version Bell Labs Research d'Unix.

Bash est largement compatible avec sh et intègre des fonctionnalités utiles du shell Korn ksh et du shell C csh. Il est destiné à être une implémentation conforme de la partie IEEE POSIX Shell and Tools de la spécification IEEE POSIX (Norme IEEE 1003.1). Il offre des améliorations fonctionnelles par rapport à sh pour une utilisation à la fois interactive et de programmation.

Alors que le système d'exploitation GNU fournit d'autres shells, y compris une version de csh, Bash est le shell par défaut . Comme les autres logiciels GNU, Bash est assez portable. Il fonctionne actuellement sur presque toutes les versions d'Unix et quelques autres systèmes d'exploitation - des ports pris en charge indépendamment existent pour les plates-formes MS-DOS, OS / 2 et Windows.


14

D'autres réponses ont généralement souligné la différence entre Bash et un standard shell POSIX. Cependant, lors de l'écriture de scripts shell portables et de l'utilisation de la syntaxe Bash, une liste de bashismes typiques et de solutions POSIX pures correspondantes est très pratique. Cette liste a été compilée lorsque Ubuntu est passé de Bash à Dash en tant que shell système par défaut et peut être trouvée ici: https://wiki.ubuntu.com/DashAsBinSh

De plus, il existe un excellent outil appelé checkbashisms qui vérifie les bashismes dans votre script et est pratique lorsque vous voulez vous assurer que votre script est portable.


C'est essentiellement ce à quoi ma réponse se résume en ce moment. +1
tripleee

8

Ils sont presque identiques mais bashont plus de fonctionnalités - shest (plus ou moins) un sous-ensemble plus ancien de bash.

shsignifie souvent l'original Bourne shell, qui est antérieur bash(Bourne *again* shell ), et a été créé en 1977. Mais, dans la pratique, il peut être préférable de le considérer comme un shell hautement compatible avec la norme POSIX de 1992.

Les scripts qui commencent par #!/bin/shou utilisent le shshell le font généralement pour une compatibilité ascendante. Tout OS unix / linux aura un shshell. Sur Ubuntu, il est shsouvent appelé dashet sur MacOS, il s'agit d'une version spéciale POSIX de bash. Ces coques peuvent être préférées pour un comportement conforme aux normes, une vitesse ou une compatibilité descendante.

bashest plus récent que l'original sh, ajoute plus de fonctionnalités et cherche à être rétrocompatible avec sh. En théorie, les shprogrammes devraient fonctionner bash. bashest disponible sur presque toutes les machines linux / unix et généralement utilisé par défaut - à l'exception notable de MacOS par défaut à zshpartir de Catalina (10.15). FreeBSD, par défaut, n'est pas fourni avec bashinstallé.


shest bien antérieure à POSIX. De nos jours, vous espérez que tout ce que shvous trouverez est au moins compatible POSIX; mais sur les systèmes existants, ce n'est en aucun cas une donnée. POSIX stadardise bien plus que le shell; en fait, vous pourriez faire valoir que la standardisation des appels du système d'exploitation et des fonctions de bibliothèque est plus importante.
tripleee

J'ai supprimé les informations sur POSIX pour le rendre moins déroutant
Ryan Taylor

3

/bin/shpeut ou non invoquer le même programme que /bin/bash.

shprend en charge au moins les fonctionnalités requises par POSIX (en supposant une implémentation correcte). Il peut également prendre en charge les extensions.

bash, le "Bourne Again Shell", implémente les fonctionnalités requises pour les extensions sh plus spécifiques à bash. L'ensemble complet d'extensions est trop long pour être décrit ici et varie selon les nouvelles versions. Les différences sont documentées dans le manuel bash. Tapez info bashet lisez la section «Fonctions Bash» (section 6 dans la version actuelle), ou lisez la documentation actuelle en ligne .


shvous donne uniquement un shell POSIX, si vous avez la bonne PATHconfiguration dans votre shell actuel. Il n'y a pas de nom de chemin défini qui vous donne un shell POSIX.
schily

Pendant longtemps, shon ne vous donnait même pas forcément un shell POSIX, sur Solaris par exemple.
tripleee

3

bash et sh sont deux coquilles différentes. Fondamentalement, bash est sh, avec plus de fonctionnalités et une meilleure syntaxe. La plupart des commandes fonctionnent de la même façon, mais elles sont différentes.Bash (bash) est l'un des nombreux shells Unix disponibles (mais les plus couramment utilisés). Bash signifie "Bourne Again SHell", et est un remplacement / amélioration du shell Bourne d'origine (sh).

Les scripts shell sont des scripts dans n'importe quel shell, tandis que les scripts Bash sont des scripts spécifiquement pour Bash. En pratique, cependant, "script shell" et "script bash" sont souvent utilisés de manière interchangeable, sauf si le shell en question n'est pas Bash.

Cela dit, vous devriez réaliser que / bin / sh sur la plupart des systèmes sera un lien symbolique et n'invoquera pas sh. Dans Ubuntu / bin / sh utilisé pour se lier à bash, comportement typique sur les distributions Linux, mais a maintenant changé pour se lier à un autre shell appelé dash. J'utiliserais bash, car c'est à peu près la norme (ou du moins la plus courante, d'après mon expérience). En fait, des problèmes surviennent lorsqu'un script bash utilise #! / Bin / sh parce que le créateur du script suppose que le lien est vers bash alors qu'il ne doit pas l'être.


0

Les différences sont aussi simples que possible: après avoir une compréhension de base, les autres commentaires postés ci-dessus seront plus faciles à saisir.

Shell - "Shell" est un programme qui facilite l'interaction entre l'utilisateur et le système d'exploitation (noyau). Il existe de nombreuses implémentations de shell disponibles, comme sh, bash, csh, zsh ... etc.

En utilisant l'un des programmes Shell, nous pourrons exécuter des commandes prises en charge par ce programme Shell.

Bash - Il dérive de B ourne- un gain Sh ell. En utilisant ce programme, nous pourrons exécuter toutes les commandes spécifiées par Shell. De plus, nous pourrons exécuter certaines commandes qui sont spécifiquement ajoutées à ce programme. Bash a une compatibilité descendante avec sh.

Sh - Il dérive de Bourne Sh ell. "sh" prend en charge toutes les commandes spécifiées dans le shell. Moyens, En utilisant ce programme, nous pourrons exécuter toutes les commandes spécifiées par Shell.

Pour plus d'informations, procédez comme suit : - https://man.cx/sh - https://man.cx/bash


Pour comprendre POSIX, lisez la réponse d' Alex. Veuillez vérifier: stackoverflow.com/a/1780614/1261003
Raihanhbh

Je n'essaie pas de comprendre POSIX. J'examine votre réponse et, à ce titre, je dois la voir, votre réponse ajoute de la valeur. Je ne pense pas.
Scratte

Je crois que ces petites clarifications aideraient un novice à comprendre plus confortablement le jargon utilisé dans les discussions ci-dessus. @Scratte
Raihanhbh

-1

Le système d'exploitation Linux propose différents types de shell. Bien que les shells aient de nombreuses commandes en commun, chaque type a des caractéristiques uniques. Étudions différents types de coques principalement utilisées.

Coquille Sh:

Sh shell est également connu sous le nom de Bourne Shell. Sh shell est le premier shell développé pour les ordinateurs Unix par Stephen Bourne aux Bell Labs d'AT & T en 1977. Il comprend de nombreux outils de script.

Coque Bash:

Bash shell signifie Bourne Again Shell. Le shell Bash est le shell par défaut dans la plupart des distributions Linux et remplace Sh Shell (le shell Sh s'exécutera également dans le shell Bash). Bash Shell peut exécuter la grande majorité des scripts shell Sh sans modification et fournir également une fonction d'édition de ligne de commande.


Il y avait un obus antérieur par Ken Thompson. Le shell Bourne a été officiellement introduit dans v7 Unix (1979).
tripleee
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.