La norme POSIX (Single UNIX Specification 4) n'est pas utile :
Si la première ligne d'un fichier de commandes shell commence par les caractères "#!" , les résultats ne sont pas spécifiés.
Ainsi, la norme implique que si vous n'avez pas #! alors il devrait exécuter un shell POSIX. Mais les shells modernes ne sont pas compatibles POSIX. L'ancien Korn Shell 88 (ksh88) exécutait le shell Bourne (proche d'un shell POSIX) sans # ! ligne, mais ksh93 casse cela, tout comme Bash. Avec ksh93 et Bash, ils exécutent leur propre shell si non # ! la ligne est présente.
Malgré l'opinion populaire, les coques Bash et Korn diffèrent. Lorsque vous écrivez un script shell, vous ne pouvez jamais être sûr de quel shell vous serez exécuté, ou même s'il sera exécuté à partir d'un autre shell (la plupart des langages de programmation peuvent exécuter d'autres programmes). Dès que vous utilisez quelque chose en dehors de la syntaxe Bourne/POSIX, vous serez saboté.
Utilisez toujours un # ! ligne, ne la laissez pas au hasard.
Le shell parent, où vous avez entré ./myscript.sh , a d'abord essayé de execve c'est là que la ligne shebang prendrait effet si elle était présente. Lorsque cela fonctionne, le parent ne connaît pas la différence entre les scripts et les ELF car le noyau s'en charge.
Le execve a échoué, donc une ancienne fonctionnalité de compatibilité Unix, antérieure à l'existence des lignes shebang, a été activée. Il a supposé qu'un fichier qui a l'autorisation d'exécution mais qui n'est pas reconnu comme un fichier exécutable valide par le noyau doit être un script shell.
Habituellement, le shell parent suppose que le script est écrit pour le même shell (un minimum de shells de type Bourne exécutent le script avec /bin/sh , bash l'exécute comme un sous-processus bash), csh fait des devinettes plus compliquées en fonction du premier caractère car il est également antérieur à shebang et il devait coexister avec Bourne shell).
Vous avez besoin d'une ligne shebang lorsque vous savez que ces suppositions seront fausses (par exemple avec le shebang est #!/usr/bin/perl ), ou lorsque vous ne faites pas confiance à l'estimation pour fonctionner de manière cohérente, ou lorsque le script doit être exécutable par un processus parent qui n'est pas un shell lui-même.
la ligne shebang est nécessaire dans le fichier et seulement s'il est destiné à être exécuté en tant qu'exécutable (par opposition à sh file.sh invocation. Ce n'est pas vraiment nécessaire au script, c'est au système de savoir comment trouver l'interpréteur.
MODIFIER :Désolé d'avoir mal lu la question. Si la ligne shebang est manquante ou non reconnue, /bin/sh est utilisé. Mais je préfère être explicite sur l'interprète.
Notez que ce comportement n'est pas universel, IIRC, seulement certains exec* la fonction familiale le fait (sans parler des différentes plates-formes), c'est donc une autre raison d'être explicite ici.