si j'écris,
#!/bin/bashecho "foo"ou
#!/bin/shecho "foo"les deux donnent la même chose. J'ai vu quelques scripts commençant par #!/bin/sh ou #!/bin/bash. Y a-t-il une différence entre eux?
bash et sh sont deux coquilles différentes. Fondamentalement bash être sh, avec plus de fonctionnalités et une meilleure syntaxe. La plupart des commandes fonctionnent de la même manière, mais elles sont différentes.
Cela dit, vous devriez réaliser /bin/sh sur la plupart des systèmes sera un lien symbolique et n'invoquera pas sh. Dans Ubuntu /bin/sh utilisé pour créer un lien vers bash, comportement typique sur les distributions Linux, mais a maintenant changé pour 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 à bash quand ce n'est pas nécessaire.
Pour plus d'informations, http://man.cx/sh, http://man.cx/bash.
Sur Linux et d'autres systèmes de type Unix, vous avez le choix entre plusieurs shells.
Le shell est responsable non seulement de dessiner votre petite invite, mais d'interpréter vos commandes, surtout si vous mettez une logique compliquée comme des tuyaux, des conditions, etc.
bash est le shell le plus couramment utilisé comme shell par défaut pour les utilisateurs de systèmes Linux. C'est un descendant spirituel des autres shells utilisés tout au long de l'histoire d'Unix. Son nom, bash est une abréviation de Bourne-Again Shell, un hommage à la coque Bourne qu'il a été conçu pour remplacer, bien qu'il incorpore également des fonctionnalités de la coque C et de la coque Korn.
C'est couru, ces jours-ci, de /bin/bash - tout système avec bash l'aura accessible ici.
Cependant, il n'y a pas que les utilisateurs qui utilisent des shells. Script (scripts shell) besoin de coquilles pour les interpréter. Lorsque vous exécutez un script shell, votre système doit démarrer un processus shell pour exécuter votre script.
Le problème est que les différents shells ont de minuscules incohérences entre eux, et quand il s'agit d'exécuter des scripts, ceux-ci peuvent être un vrai problème. bash a beaucoup de fonctionnalités de script qui ne sont uniques qu'à bash, et pas à d'autres shells. C'est bien, si vous allez toujours utiliser bash pour exécuter ces scripts. D'autres shells peuvent essayer soit d'émuler bash, soit d'adhérer au standard POSIX, que bash supporte assez bien (bien qu'il ajoute ses propres extensions).
Il est possible de spécifier en haut d'un script shell avec quel shell il doit être exécuté en utilisant un shebang. Un script peut spécifier #!/bin/bash sur la première ligne, ce qui signifie que le script doit toujours être exécuté avec bash, plutôt qu'avec un autre shell.
/bin / sh est un exécutable représentant le coquille de système. En fait, il est généralement implémenté comme un lien symbolique pointant vers l'exécutable pour le shell système. Le shell système est en quelque sorte le shell par défaut que les scripts système doivent utiliser. Dans les distributions Linux, pendant longtemps, il s'agissait généralement d'un lien symbolique vers bash, à tel point qu'il est devenu un peu une convention de toujours lier /bin/sh à bash ou à un shell compatible bash. Cependant, au cours des deux dernières années, Debian (et Ubuntu) ont décidé de changer le shell système de bash à tiret - une rupture de shell similaire avec une longue tradition sous Linux (enfin, GNU) d'utiliser bash pour /bin/sh. Dash est considéré comme un shell plus léger et beaucoup plus rapide, ce qui peut être bénéfique pour la vitesse de démarrage (et d'autres choses qui nécessitent beaucoup de scripts shell, comme les scripts d'installation de packages).
Dash est assez bien compatible avec bash, étant basé sur le même standard POSIX. Cependant, il n'implémente pas les extensions spécifiques à bash. Il existe des scripts qui utilisent #!/bin/sh (le shell système) comme leur shebang, mais qui nécessitent des extensions spécifiques à bash. Ceci est actuellement considéré comme un bug qui devrait être corrigé par Debian et Ubuntu, qui ont besoin de /bin / sh pour pouvoir fonctionner lorsqu'il est pointé vers dash.
Même si Ubuntu coquille de système pointe vers dash, votre shell de connexion en tant qu'utilisateur continue d'être bash pour le moment. Autrement dit, lorsque vous vous connectez à un émulateur de terminal n'importe où sous Linux, votre shell de connexion sera bash. La vitesse de fonctionnement n'est pas tellement un problème lorsque le shell est utilisé de manière interactive et que les utilisateurs sont familiers avec bash (et peuvent avoir des personnalisations spécifiques à bash dans leur répertoire personnel).
Ce que vous devez utiliser lors de l'écriture de scripts
Si votre script nécessite des fonctionnalités uniquement prises en charge par bash, utilisez #!/bin/bash.
Mais si possible, il serait bon de s'assurer que votre script est compatible POSIX et d'utiliser #!/bin/sh, qui devrait toujours, de manière assez fiable, pointer vers le shell système compatible POSIX préféré dans toute installation.
En plus des réponses précédentes, même si /bin/sh est un lien symbolique vers /bin/bash, #!/bin/sh n'est pas totalement équivalent à #!/bin/bash.
De la bash (1) page de manuel :
"Si bash est invoqué avec le nom sh, il essaie d'imiter le comportement de démarrage des versions historiques de sh aussi étroitement que possible, tout en se conformant également à la norme POSIX."
Par exemple la syntaxe spécifique à bash :
exec > >(tee logfile.txt)donne une erreur dans un shell commençant par #!/bin/sh>, même avec le lien symbolique sh-bash en place.
GNU Bash: #!/bin/bash; Shell POSIX: #!/bin/sh.