Quand dois-je utiliser #!/bin/bash et quand #!/bin/sh ?

Utilisez le shebang correspondant au Shell que vous avez effectivement utilisé pour développer et déboguer votre Shell. C'est-à-dire que si votre Shell de connexion est bash et vous lancez votre script comme exécutable dans votre terminal, utilisez #!/bin/bash . Ne présumez pas que, puisque vous n'avez pas utilisé de tableaux (ou autre) bash que vous connaissez), vous pouvez choisir n'importe quel Shell que vous voulez. Il existe de nombreuses différences subtiles entre les shells ( echo (fonctions, boucles, etc.) qui ne peuvent être découverts sans un test approprié.

Considérez ceci : si vous laissez #!/bin/bash et que vos utilisateurs ne l'ont pas, ils verront un message d'erreur clair, quelque chose comme

Error: /bin/bash not found

La plupart des utilisateurs peuvent résoudre ce problème en moins d'une minute en installant le paquet approprié. D'un autre côté, si vous remplacez le shebang par #!/bin/sh et le tester sur un système où /bin/sh est un lien symbolique vers /bin/bash vos utilisateurs qui n'ont pas bash sera en difficulté. Ils verront probablement un message d'erreur cryptique du genre :

Error in script.sh line 123: error parsing token xyz

Cela peut prendre des heures à réparer, et il n'y aura aucun indice sur le Shell qu'ils auraient dû utiliser.

Il n'y a pas beaucoup de raisons pour lesquelles vous voudriez utiliser un Shell différent dans le shebang. Une raison est lorsque le Shell que vous avez utilisé n'est pas répandu. Une autre est de gagner en performance avec sh qui est nettement plus rapide sur certains systèmes, ET votre script sera un goulot d'étranglement en termes de performances. Dans ce cas, testez votre script minutieusement avec le script cible, puis changez le shebang.

Généralement, si le temps est plus important que la fonctionnalité, vous utiliserez le plus rapide Shell. sh est souvent aliasé en dash et tend à être utilisé pour les tâches cron de root ou les opérations par lots où chaque (nano) seconde compte.

Vous ne devriez jamais utiliser #! /bin/sh .

Vous ne devez pas utiliser les extensions bash (ou zsh, ou fish, ou ...) dans un Shell Shell, jamais.

Vous ne devriez jamais écrire Shell Shell qui fonctionnent avec tout implémentation du langage Shell (y compris tous les programmes "utilitaires" qui vont de pair avec le Shell lui-même). De nos jours, vous pouvez probablement prendre POSIX.1-2001 ( no -2008) comme faisant autorité pour ce dont le Shell et les utilitaires sont capables, mais soyez conscient que vous pouvez un jour être appelé à porter votre Shell sur un système hérité (par exemple Solaris ou AIX) dont le Shell et les utilitaires ont été gelés vers 1992.

Quoi, sérieusement ? !

Oui, sérieusement.

Voilà le truc : Shell est un terrible le langage de programmation. La seule chose qu'il a en sa faveur est que /bin/sh est le seul et unique interprète de script qui chaque L'installation Unix est garantie.

Autre chose : une itération de l'interpréteur Perl 5 de base ( /usr/bin/perl ) est plus susceptibles d'être disponibles sur une installation Unix sélectionnée au hasard que (/(usr|opt)(/(local|sfw|pkg)?)?/bin/bash est. D'autres bons langages de script (Python, Ruby, node.js, etc. - j'inclurai même PHP et Tcl dans cette catégorie lors de la comparaison avec Shell) sont également à peu près aussi disponibles que bash et d'autres shells étendus.

Par conséquent, si vous avez la possibilité d'écrire un script bash, vous avez la possibilité d'utiliser un langage de programmation qui n'est pas terrible, à la place.

Maintenant, simple Shell Shell, le genre qui exécute juste quelques programmes dans une séquence à partir d'un travail cron ou autre, il n'y a rien de mal à les laisser comme Shell Shell. Mais les simples Shell Shell n'ont pas besoin de tableaux ou de fonctions ou de [[ même. Et vous devriez seulement écrire compliqué Shell Shell quand vous n'avez pas d'autre choix. Les Shell d'Autoconf, par exemple, sont toujours correctement Shell Shell. Mais ces Shell doivent s'exécuter sur chaque l'incarnation de /bin/sh qui est pertinent pour le programme en cours de configuration. et cela signifie qu'ils ne peuvent pas utiliser d'extensions. Vous n'avez probablement pas à vous soucier des vieux Unix propriétaires de nos jours, mais vous avez probablement devrait se soucier des BSDs open-source actuels, dont certains n'installent pas bash par défaut, et des environnements intégrés qui ne vous donnent qu'un Shell minimal et des busybox .

En conclusion, au moment où vous vous trouvez voulant une fonctionnalité qui n'est pas disponible dans le langage portable Shell, c'est un signe que le Shell est devenu trop compliqué pour rester un Shell Shell. Réécrivez-le dans un meilleur langage à la place.

Pour être encore plus bref, utilisez sh si la portabilité à travers la plupart des systèmes est la plus importante et bash si vous souhaitez utiliser certaines de ses fonctionnalités spécifiques, comme les tableaux, si la version de bash le supporte.