¿Por qué es mejor usar "#! / Usr / bin / env NAME" en lugar de "#! / Path / to / NAME" como mi shebang?

Noté que algunos scripts que he adquirido de otros tienen el shebang #!/path/to/NAMEmientras que otros (usando la misma herramienta, NAME) tienen el shebang #!/usr/bin/env NAME.

Ambos parecen funcionar correctamente. En los tutoriales (en Python, por ejemplo), parece haber una sugerencia de que este último shebang es mejor. Pero, no entiendo por qué esto es así.

Me doy cuenta de que, para usar el último shebang, NAME debe estar en la RUTA, mientras que el primer shebang no tiene esta restricción.

Además, parece (para mí) que el primero sería el mejor shebang, ya que especifica con precisión dónde se encuentra NAME. Entonces, en este caso, si hay varias versiones de NAME (por ejemplo, / usr / bin / NAME, / usr / local / bin / NAME), el primer caso especifica cuál usar.

Mi pregunta es ¿por qué se prefiere el primer shebang al segundo?

No es necesariamente mejor.

La ventaja de esto #!/usr/bin/env pythones que usará cualquier pythonejecutable que aparezca primero en el usuario $PATH.

La desventaja de #!/usr/bin/env pythones que va a utilizar cualquier pythonejecutable aparece por primera vez en el usuario de $PATH.

Eso significa que el script podría comportarse de manera diferente dependiendo de quién lo ejecute. Para un usuario, podría usar el /usr/bin/pythonque se instaló con el sistema operativo. Por otro lado, podría usar un experimental /home/phred/bin/pythonque no funciona correctamente.

Y si pythonsólo se instala en /usr/local/bin, un usuario que no tiene /usr/local/binen $PATHni siquiera será capaz de ejecutar el script. (Eso probablemente no sea muy probable en los sistemas modernos, pero podría suceder fácilmente para un intérprete más oscuro).

Al especificar #!/usr/bin/python, especifica exactamente qué intérprete se utilizará para ejecutar el script en un sistema en particular .

Otro problema potencial es que el #!/usr/bin/envtruco no le permite pasar argumentos al intérprete (aparte del nombre del script, que se pasa implícitamente). Esto generalmente no es un problema, pero puede serlo. Muchos scripts de Perl están escritos con #!/usr/bin/perl -w, pero use warnings;es el reemplazo recomendado en estos días. Los scripts Csh deberían usar #!/bin/csh -f, pero los scripts csh no se recomiendan en primer lugar. Pero podría haber otros ejemplos.

Tengo varias secuencias de comandos Perl en un sistema de control de fuente personal que instalo cuando configuro una cuenta en un nuevo sistema. Utilizo un script de instalador que modifica la #!línea de cada script a medida que lo instala en mi $HOME/bin. (No he tenido que usar nada más que #!/usr/bin/perlúltimamente; se remonta a los tiempos en que Perl a menudo no se instalaba de manera predeterminada).

Un punto menor: el #!/usr/bin/envtruco es posiblemente un abuso del envcomando, que originalmente tenía la intención (como su nombre lo indica) de invocar un comando con un entorno alterado. Además, algunos sistemas más antiguos (incluido SunOS 4, si no recuerdo mal) no tenían el envcomando /usr/bin. Es probable que ninguno de estos sea una preocupación importante. envfunciona de esta manera, muchos scripts utilizan el #!/usr/bin/envtruco, y es probable que los proveedores de sistemas operativos no hagan nada para romperlo. Que podría ser un problema si usted quiere que su secuencia de comandos para ejecutar en un sistema muy viejo, pero entonces es muy probable que tenga que modificar todos modos.

Otro posible problema, (gracias a Sopalajo de Arrierez por señalarlo en los comentarios) es que los trabajos cron se ejecutan con un entorno restringido. En particular, $PATHes típicamente algo así /usr/bin:/bin. Entonces, si el directorio que contiene el intérprete no se encuentra en uno de esos directorios, incluso si está en su $PATHshell predeterminado de usuario, entonces el /usr/bin/envtruco no funcionará. Puede especificar la ruta exacta, o puede agregar una línea a su crontab para establecer $PATH( man 5 crontabpara más detalles).

Porque / usr / bin / env puede interpretar tu $PATH, lo que hace que los scripts sean más portátiles.

#!/usr/local/bin/python

Solo ejecutará su script si python está instalado en / usr / local / bin.

#!/usr/bin/env python

Interpretará su $PATH, y encontrará python en cualquier directorio en su $PATH.

Por lo tanto, su script es más portátil y funcionará sin modificaciones en los sistemas donde python está instalado como /usr/bin/python, o /usr/local/bin/python, o incluso en directorios personalizados (que se han agregado a $PATH), como /opt/local/bin/python.

La portabilidad es la única razón por la que envse prefiere el uso a las rutas codificadas.

Especificar la ruta absoluta es más precisa en un sistema dado. La desventaja es que es demasiado preciso. Suponga que se da cuenta de que la instalación del sistema de Perl es demasiado antigua para sus scripts y desea utilizar el suyo en su lugar: luego tiene que editar los scripts y cambiar #!/usr/bin/perla #!/home/myname/bin/perl. Peor aún, si tiene Perl en /usr/binalgunas máquinas, /usr/local/binen otras y /home/myname/bin/perlen otras máquinas, deberá mantener tres copias separadas de los scripts y ejecutar la correspondiente en cada máquina.

#!/usr/bin/envse rompe si PATHes malo, pero también lo hace casi todo. Intentar operar con un mal PATHrara vez es útil e indica que sabe muy poco sobre el sistema en el que se ejecuta el script, por lo que no puede confiar en ninguna ruta absoluta de todos modos.

Hay dos programas cuya ubicación puede confiar en casi todas las variantes de Unix: /bin/shy /usr/bin/env. Algunas variantes de Unix oscuras y en su mayoría retiradas tenían /bin/envsin tener /usr/bin/env, pero es poco probable que las encuentres. Los sistemas modernos tienen /usr/bin/envprecisamente debido a su uso generalizado en shebangs. /usr/bin/enves algo con lo que puedes contar.

Además /bin/sh, la única vez que debe usar una ruta absoluta en un shebang es cuando su script no debe ser portátil, por lo que puede contar con una ubicación conocida para el intérprete. Por ejemplo, un script bash que solo funciona en Linux puede usarse de manera segura #!/bin/bash. Un script que solo debe usarse internamente puede basarse en las convenciones de ubicación del intérprete interno.

#!/usr/bin/envTiene inconvenientes. Es más flexible que especificar una ruta absoluta, pero aún requiere conocer el nombre del intérprete. Ocasionalmente, es posible que desee ejecutar un intérprete que no esté en $PATH, por ejemplo, en una ubicación relativa al script. En tales casos, a menudo puede crear un script políglota que puede ser interpretado tanto por el shell estándar como por el intérprete deseado. Por ejemplo, para hacer que un script de Python 2 sea portátil tanto en sistemas donde pythonestá Python 3 y python2Python 2 como en sistemas donde pythonestá Python 2 y python2no existe:

#!/bin/sh
''':'
if type python2 >/dev/null 2>/dev/null; then
  exec python2 "$0" "$@"
else
  exec python "$0" "$@"
fi
'''
# real Python script starts here
def …

Específicamente para Perl, usar #!/usr/bin/enves una mala idea por dos razones.

Primero, no es portátil. En algunas plataformas oscuras, env no está en / usr / bin. En segundo lugar, como ha señalado Keith Thompson , puede causar problemas para pasar argumentos en la línea shebang. La solución máximamente portátil es esta:

#!/bin/sh
exec perl -x "$0" "$@"
#!perl

Para obtener detalles sobre cómo funciona, consulte 'perldoc perlrun' y lo que dice sobre el argumento -x.

La razón por la que hay una distinción entre los dos es por cómo se ejecutan los scripts.

Se requiere el uso /usr/bin/env(que, como se mencionó en otras respuestas, no está en /usr/binalgunos sistemas operativos) porque no puede simplemente poner un nombre ejecutable después de #!- debe ser una ruta absoluta. Esto se debe a que el #!mecanismo funciona en un nivel más bajo que el shell. Es parte del cargador binario del núcleo. Esto puede ser probado. Ponga esto en un archivo y márquelo como ejecutable:

#!bash

echo 'foo'

Encontrará que imprime un error como este cuando intenta ejecutarlo:

Failed to execute process './test.sh'. Reason:
The file './test.sh' does not exist or could not be executed.

Si un archivo está marcado como ejecutable y comienza con a #!, el núcleo (que no conoce $PATHo el directorio actual: estos son conceptos de usuario) buscará un archivo utilizando una ruta absoluta. Debido a que usar una ruta absoluta es problemático (como se menciona en otras respuestas), a alguien se le ocurrió un truco: puede ejecutar /usr/bin/env(que casi siempre está en esa ubicación) para ejecutar algo usando $PATH.

Hay dos problemas más con el uso #!/usr/bin/env

1. No resuelve el problema de especificar la ruta completa al intérprete, simplemente lo mueve env.

   envno se garantiza más que esté dentro de lo /usr/bin/envque bashse garantiza que esté dentro /bin/basho python in /usr/bin/python.

2. env sobrescribe ARGV [0] con el nombre del intérprete (por ejemplo, bash o python).

   Esto evita que aparezca el nombre de su script, por ejemplo, en la pssalida (o cambia cómo / dónde aparece) y hace que sea imposible encontrarlo, por ejemplo,ps -C scriptname.sh

[actualización 2016-06-04]

Y un tercer problema:

3. Cambiar su RUTA es más trabajo que simplemente editar la primera línea de un guión, especialmente cuando el guión de tales ediciones es trivial. p.ej:

   printf "%s\n" 1 i '#!'$(type -P python2) . w | ed foo.py

   Anexar o pre-pendiente un directorio a $ PATH es bastante fácil (aunque todavía tiene que editar un archivo para que sea permanente, su ~/.profileo lo que sea) y está lejos de ser fácil de escribir ESE edición porque la RUTA podría establecerse en cualquier parte del script , no en la primera línea).

   Cambiar el orden de los directorios PATH es significativamente más difícil ... y mucho más difícil que simplemente editar la #!línea.

   Y todavía tiene todos los otros problemas que #!/usr/bin/envle da el uso .

   @jlliagre sugiere en un comentario que #!/usr/bin/enves útil para probar su secuencia de comandos con múltiples versiones de intérpretes, "solo cambiando su orden PATH / PATH"

   Si necesita hacer eso, es mucho más fácil tener varias #!líneas en la parte superior de su script (son solo comentarios en cualquier lugar menos la primera línea) y cortar / copiar y pegar la que desea usar ahora para La primera línea.

   En vi, eso sería tan simple como mover el cursor al#! línea que desea, luego escribir dd1GPo Y1GP. Incluso con un editor tan trivial como nano, usaría el mouse para copiar y pegar tomaría segundos.

En general, las ventajas de usar #!/usr/bin/envson mínimas en el mejor de los casos, y ciertamente ni siquiera se acercan a superar las desventajas. Incluso la ventaja de "conveniencia" es en gran medida ilusoria.

En mi opinión, es una idea tonta promovida por un tipo particular de programador que cree que los sistemas operativos no son algo con lo que se pueda trabajar, son un problema que se debe solucionar (o ignorar en el mejor de los casos).

PD: aquí hay un script simple para cambiar el intérprete de varios archivos a la vez.

change-shebang.sh:

#!/bin/bash

interpreter="$1"
shift

if [ -z "$(type -P $interpreter)" ] ; then
  echo "Error: '$interpreter' is not executable." >&2
  exit 1
fi

if [ ! -d "$interpreter" ] && [ -x "$interpreter" ] ; then
  shebang='#!'"$(realpath -e $interpreter)" || exit 1
else
  shebang='#!'"$(type -P $interpreter)"
fi

for f in "$@" ; do
  printf "%s\n" 1 i "$shebang" . w | ed "$f"
done

Ejecútelo como, por ejemplo, change-shebang.sh python2.7 *.pyochange-shebang.sh $HOME/bin/my-experimental-ruby *.rb

Añadiendo otro ejemplo aquí:

El uso envtambién es útil cuando desea compartir scripts entre múltiples rvmentornos, por ejemplo.

Al ejecutar esto en la línea cmd, se muestra qué versión de ruby ​​se usará cuando #!/usr/bin/env rubyse use dentro de un script:

env ruby --version

Por lo tanto, cuando usa env, puede usar diferentes versiones de ruby ​​a través de rvm, sin cambiar sus scripts.

Si está escribiendo exclusivamente para usted o para su trabajo y la ubicación del intérprete al que llama siempre está en el mismo lugar, utilice la ruta directa. En todos los demás casos, use #!/usr/bin/env.

He aquí por qué: en su situación, el pythonintérprete estaba en el mismo lugar, independientemente de la sintaxis que utilizó, pero para muchas personas podría haberse instalado en un lugar diferente. Aunque la mayoría de los principales intérpretes de programación se encuentran en /usr/bin/una gran cantidad de software más nuevo, está predeterminado /usr/local/bin/.

Incluso argumentaría que siempre se #!/usr/bin/envdebe usar porque si tiene instaladas varias versiones del mismo intérprete y no sabe cuál será el valor predeterminado de su shell, entonces probablemente debería solucionarlo.

Por razones de portabilidad y compatibilidad, es mejor usar

#!/usr/bin/env bash

en lugar de

#!/usr/bin/bash

Hay múltiples posibilidades, donde un binario puede estar ubicado en un sistema Linux / Unix. Consulte la página de manual de hier (7) para obtener una descripción detallada de la jerarquía del sistema de archivos.

FreeBSD, por ejemplo, instala todo el software, que no es parte del sistema base, en / usr / local / . Dado que bash no es parte del sistema base, el binario bash se instala en / usr / local / bin / bash .

Cuando desee un script portátil bash / csh / perl / whatever, que se ejecuta en la mayoría de las distribuciones de Linux y FreeBSD, debe usar #! / Usr / bin / env .

También tenga en cuenta que la mayoría de las instalaciones de Linux también han vinculado (duro) el binario env a / bin / env o softlinked / usr / bin a / bin que no debe usarse en el shebang. Así que no uses #! / Bin / env .