Emplacement du programmeEdit
Les Shebangs doivent spécifier des chemins absolus (ou des chemins relatifs au répertoire de travail actuel) vers les exécutables du système ; cela peut causer des problèmes sur les systèmes qui ont une disposition non standard du système de fichiers. Même lorsque les systèmes ont des chemins assez standard, il est tout à fait possible que des variantes d’un même système d’exploitation aient des emplacements différents pour l’interpréteur souhaité. Python, par exemple, pourrait être dans /usr/bin/python3, /usr/local/bin/python3, ou même quelque chose comme /home/username/bin/python3 s’il est installé par un utilisateur ordinaire.
Un problème similaire existe pour l’interpréteur de commandes POSIX, puisque POSIX a seulement exigé que son nom soit sh, mais n’a pas mandaté de chemin. Une valeur courante est /bin/sh, mais certains systèmes comme Solaris ont le shell compatible POSIX à /usr/xpg4/bin/sh. Dans de nombreux systèmes Linux, /bin/sh est un lien dur ou symbolique vers /bin/bash, le Bourne Again shell (BASH). Utiliser une syntaxe spécifique à BASH tout en maintenant un shebang pointant vers sh n’est pas non plus portable.
À cause de cela, il est parfois nécessaire d’éditer la ligne shebang après avoir copié un script d’un ordinateur à un autre, car le chemin qui a été codé dans le script peut ne pas s’appliquer sur une nouvelle machine, selon la cohérence de la convention passée de placement de l’interpréteur. Pour cette raison et parce que POSIX ne standardise pas les noms de chemin, POSIX ne standardise pas cette fonctionnalité. L’outil GNU Autoconf peut tester le support du système avec la macro AC_SYS_INTERPRETER.
Souvent, le programme /usr/bin/env peut être utilisé pour contourner cette limitation en introduisant un niveau d’indirection. #! est suivi de /usr/bin/env, suivi de la commande désirée sans le chemin complet, comme dans cet exemple :
#!/usr/bin/env sh
Cela fonctionne surtout parce que le chemin /usr/bin/env est couramment utilisé pour l’utilitaire env,et qu’il invoque le premier sh trouvé dans le $PATH de l’utilisateur, typiquement /bin/sh.
Cela pose encore quelques problèmes de portabilité avec OpenServer 5.0.6 et Unicos 9.0.2 qui n’ont que /bin/env et pas /usr/bin/env.
Interprétation des caractèresEdit
Un autre problème de portabilité est l’interprétation des arguments de la commande.Certains systèmes, dont Linux, ne séparent pas les arguments ; par exemple, lors de l’exécution du script avec la première ligne comme,
#!/usr/bin/env python3 -c
tout le texte après le premier espace est traité comme un seul argument, c’est-à-dire que python3 -c sera passé comme un seul argument à /usr/bin/env, plutôt que deux arguments. Cygwin se comporte également de cette façon.
Les invocations d’interpréteurs complexes sont possibles grâce à l’utilisation d’un wrapper supplémentaire. FreeBSD 6.0 (2005) a introduit une option -S à son env en changeant le comportement de lecture shebang en non-splitting. Cette option indique à env de diviser la chaîne elle-même. L’utilitaire GNU env depuis coreutil 8.30 (2018) inclut également cette fonctionnalité. Bien que l’utilisation de cette option atténue le problème de portabilité du côté du noyau avec le fractionnement, elle ajoute l’exigence que env prenne en charge cette extension particulière.
Un autre problème est celui des scripts contenant un caractère de retour chariot immédiatement après la ligne shebang, peut-être à la suite d’une édition sur un système qui utilise des sauts de ligne DOS, comme Microsoft Windows. Certains systèmes interprètent le caractère de retour chariot comme faisant partie de la commande de l’interpréteur, ce qui entraîne un message d’erreur.
Numéro magiqueEdit
Le shebang est en fait une instance lisible par l’homme d’un numéro magique dans le fichier exécutable, la chaîne d’octets magique étant 0x23 0x21, l’encodage à deux caractères en ASCII de # ! Ce nombre magique est détecté par la famille de fonctions « exec », qui détermine si un fichier est un script ou un binaire exécutable. La présence du shebang entraîne l’exécution de l’exécutable spécifié, généralement un interpréteur pour le langage du script. Il a été prétendu que certaines anciennes versions d’Unix s’attendent à ce que le shebang normal soit suivi d’un espace et d’une barre oblique (# ! /), mais cela semble faux ; au contraire, les blancs après le shebang ont traditionnellement été autorisés, et parfois documentés avec un espace (voir le courriel de 1980 dans la section historique ci-dessous).
Les caractères shebang sont représentés par les deux mêmes octets dans les codages ASCII étendus, y compris UTF-8, qui est couramment utilisé pour les scripts et autres fichiers texte sur les systèmes actuels de type Unix. Toutefois, les fichiers UTF-8 peuvent commencer par la marque d’ordre d’octet (BOM) facultative ; si la fonction « exec » détecte spécifiquement les octets 0x23 et 0x21, la présence de la BOM (0xEF 0xBB 0xBF) avant le shebang empêchera l’exécution de l’interpréteur de script. Certaines autorités recommandent de ne pas utiliser la marque d’ordre d’octet dans les scripts POSIX (Unix-like), pour cette raison et pour des préoccupations plus larges d’interopérabilité et de philosophie. En outre, une marque d’ordre d’octet n’est pas nécessaire en UTF-8, car cet encodage n’a pas de problèmes d’endianness ; elle sert uniquement à identifier l’encodage comme UTF-8.