Y a-t-il une garantie que / usr / bin / env existera?

8

Souvent, je vois des scripts commencer par une ligne de shebang qui utilise #!/usr/bin/env interpreter_namepour n'importe quel interprète, avec la justification que différents systèmes peuvent avoir l'interpréteur dont ils ont besoin pour fonctionner installé à différents endroits. Par exemple, si je suppose qu'il pythonest installé /usr/bin/pythonalors un utilisateur qui a décidé de l'installer car /opt/pythonpour une raison quelconque ne pourra pas l'utiliser aussi facilement.

Mais la question évidente est la suivante: existe-t-il une garantie qui envsera installée à /usr/bin/env(ou d'ailleurs à un endroit particulier), ou s'agit-il simplement de "déplacer le problème" pour ainsi dire?

Cette question légèrement liée a un commentaire qui dit que c'est une mauvaise idée et qu'il est préférable de l'installer avec le chemin réel de l'interpréteur et cite la spécification Unix unique mais ne répond pas vraiment à cette question.

scripting env scott_fakename
la source

Réponses:

6

Non, il envn'est pas garanti d'être dans /usr/bin, comme vous pouvez le lire dans l' historique du mécanisme shebang , dans la section "L'utilitaire env":

Cependant, l'emplacement d'env (1) peut varier. Free-, Net-, OpenBSD et certaines distributions Linux (par exemple Debian) ne viennent qu'avec / usr / bin / env. D'un autre côté, il n'y a que / bin / env au moins sur SCO OpenServer 5.0.6 et Cray Unicos 9.0.2 (bien que ce dernier ne présente qu'un intérêt historique). Sur certaines autres distributions Linux (Redhat), il est situé dans / bin et / usr / bin / contient un lien symbolique pointant vers lui.

Il ne déplace pas complètement le problème, en raison de la flexibilité de la envrecherche $PATH. Si vous arrive d'obtenir des scripts qui utilisent un autre emplacement pour envde la vôtre, vous ne devez savoir sur l' endroit où vos envvies, et non aussi où perl, pythonpeut - être installé, et d' autres interprètes.

Et vous n'avez pas à coder en dur /opt/python/3.3.2/bin/python3.3s'il s'agit du premier python3.3exécutable de votre PATH. Vous pouvez simplement compter sur le envtrouver, vous n'avez donc pas à mettre à jour chaque script si vous effectuez une mise à niveau pour utiliser /opt/python/3.3.3/bin/python3.3. Votre en-tête de script reste le même:

#! /usr/bin/env python3.3
Anthon
la source
Aha. Je vous remercie. Je n'ai trouvé aucune information à ce sujet. Quand j'ai dit "déplacer" le problème, je voulais dire qu'au lieu de chercher python perletc, vous n'avez plus qu'à traquer env, donc le même problème, mais une cible différente. Il semble que ce envsoit beaucoup plus facile à trouver et évidemment beaucoup plus polyvalent, donc c'est toujours très favorable. Ce qui répond parfaitement à ma question. Je vous remercie!
scott_fakename