Ce n'est pas forcément mieux.
L'avantage #!/usr/bin/env python
est qu'il utilisera le python
fichier exécutable qui apparaît en premier dans l'utilisateur $PATH
.
L' inconvénient de #!/usr/bin/env python
est qu'il utilisera le python
fichier exécutable qui apparaît en premier dans l'utilisateur $PATH
.
Cela signifie que le script peut se comporter différemment selon son exécution. Pour un utilisateur, il peut utiliser l’ /usr/bin/python
installation du système d’exploitation. D'autre part, il pourrait utiliser un expérimental /home/phred/bin/python
qui ne fonctionne pas correctement.
Et s’il python
n’est installé que dans /usr/local/bin
, un utilisateur qui n’a pas /usr/local/bin
in $PATH
ne pourra même pas exécuter le script. (Ce n'est probablement pas trop probable sur les systèmes modernes, mais cela pourrait facilement arriver à un interprète plus obscur.)
En spécifiant, #!/usr/bin/python
vous spécifiez exactement quel interpréteur sera utilisé pour exécuter le script sur un système particulier .
Un autre problème potentiel est que l' #!/usr/bin/env
astuce ne vous permet pas de transmettre des arguments à l'intrepreter (autre que le nom du script, qui est transmis de manière implicite). Ce n'est généralement pas un problème, mais ça peut l'être. De nombreux scripts Perl sont écrits avec #!/usr/bin/perl -w
, mais use warnings;
c'est le remplacement recommandé de nos jours. Les scripts Csh doivent utiliser #!/bin/csh -f
- mais les scripts csh ne sont pas recommandés en premier lieu. Mais il pourrait y avoir d'autres exemples.
J'ai un certain nombre de scripts Perl dans un système de contrôle de source personnel que j'installe lorsque je crée un compte sur un nouveau système. J'utilise un script d'installation qui modifie la #!
ligne de chaque script à mesure qu'il l'installe dans mon fichier $HOME/bin
. (Je n'ai pas eu à utiliser autre chose que #!/usr/bin/perl
récemment; cela remonte à une époque où Perl n'était souvent pas installé par défaut.)
Un point mineur: le #!/usr/bin/env
truc est sans doute un abus de la env
commande, qui était à l'origine destiné (comme son nom l'indique) à appeler une commande avec un environnement modifié. En outre, certains systèmes plus anciens (y compris SunOS 4, si ma mémoire est bonne) ne disposaient pas de la env
commande /usr/bin
. Ni l'un ni l'autre ne sont susceptibles d'être une préoccupation importante. env
fonctionne de cette façon, beaucoup de scripts utilisent cette #!/usr/bin/env
astuce et les fournisseurs de système d’exploitation ne feront probablement rien pour la résoudre. Cela peut poser problème si vous voulez que votre script soit exécuté sur un système très ancien, mais vous devrez probablement le modifier quand même.
Un autre problème possible (merci à Sopalajo de Arrierez de l'avoir signalé dans les commentaires) est que les tâches cron s'exécutent dans un environnement restreint. En particulier, $PATH
est généralement quelque chose comme /usr/bin:/bin
. Donc, si le répertoire contenant l'interpréteur ne se trouve pas dans l'un de ces répertoires, même s'il est dans votre répertoire $PATH
utilisateur par défaut , alors l' /usr/bin/env
astuce ne fonctionnera pas. Vous pouvez spécifier le chemin exact ou ajouter une ligne à votre crontab à définir $PATH
( man 5 crontab
pour plus de détails).