Re: le langage est bash, donc le langage est bash

C’est toujours le cas car c’est ce qui est demandé.

$ cat script-python
#! /usr/bin/env python2
print "bonjour tout le monde"
$ ./script-python
bonjour tout le monde
$ python2 script-python
bonjour tout le monde
$ python3 script-python
 File "script-python", line 2
 print "bonjour tout le monde"
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
SyntaxError: Missing parentheses in call to 'print'. Did you mean print(...)?
$ ruby script-python
ruby: no Ruby script found in input (LoadError)

C’est le shebang qui détermine l’interpréteur, à moins que l’utilisateur ne force un autre.

Ce n’est pas qu’une affaire de script, c’est vrai aussi pour le code compilé:

$ file /usr/bin/whoami
/usr/bin/whoami: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=064a1abc92933fda978fa7d97250c1bf12c65e46, for GNU/Linux 3.2.0, stripped
$ LANG=C.UTF-8 readelf -l /usr/bin/whoami | grep 'Requesting program interpreter'
 [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
$ /usr/bin/whoami
illwieckz
$ /lib64/ld-linux-x86-64.so.2 /usr/bin/whoami
illwieckz
$ /usr/i686-linux-gnu/lib/ld-linux.so.2 /usr/bin/whoami
/usr/bin/whoami: error while loading shared libraries: /usr/bin/whoami: wrong ELF class: ELFCLASS64
$ /usr/aarch64-linux-gnu/lib/ld-linux-aarch64.so.1 /usr/bin/whoami
/usr/bin/whoami: error while loading shared libraries: /usr/bin/whoami: cannot open shared object file: No such file or directory

Ça veut d’ailleurs dire qu’on peut techniquement passer des paramètres dans le shebang:

$ cat test
#! /usr/bin/bash -x
echo test
$ ./test
+ echo test
test

Bon, mais ne faites pas ça, la façon standard d’appeler un interpréteur c’est /usr/bin/env <interpréteur>, et rajouter des paramètres risque de casser la détection du langage par les non-interpréteurs (comme les éditeurs pour activer la bonne coloration syntaxiques).

Si vous ne renseignez pas l’interpréteur correctement les outils non-interpréteurs seront perdus car c’est ce qu’ils regardent, et le shebang est bien plus fiable que l’extension: il ne peut pas mentir. Le shebang est non-ambigu, ajouter une extension à un programme pensé pour être appelé depuis un shell, saymal:

• https://www.talisman.org/~erlkonig/documents/commandname-extensions-considered-harmful/

Ajouter une extension comme un .py c’est utile pour une bibliothèque par exemple, mais pour appeler une commande, ajouter une extension c’est très très mal. En dehors de ce genre de cas de bibliothèque, ajouter une extension à un script c’est généralement pour contourner les limitations de Windows qui ne regarde pas l’entête du fichier pour déterminer son format.

Mais là encore, derrière le gang qui salit les scripts en y ajoutant des extensions, il y a un culte du cargo entretenus par ceux qui ont imité des Windowsiens, reproduisant par mimétisme les gestes sans comprendre pourquoi ces Windowsiens faisaient ainsi, Windowsiens pour qui ces rites participent en fait à leur stratégie d’évitement et de résilience face à la souffrance que Windows leur cause.

ce commentaire est sous licence cc by 4 et précédentes