GNU/Linux >> Tutoriales Linux >  >> Linux

¿Por qué es mejor usar “#!/usr/bin/env Name” en lugar de “#!/path/to/name” como Shebang?

Me doy cuenta de que algunos scripts que he adquirido de otros tienen el shebang #!/path/to/NAME mientras que otros (usando la misma herramienta, NOMBRE) 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 es mejor. Pero, no entiendo muy bien por qué esto es así.

Me doy cuenta de que, para usar el último shebang, NOMBRE 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 NOMBRE. Entonces, en este caso, si hay varias versiones de NOMBRE (p. ej., /usr/bin/NOMBRE, /usr/local/bin/NOMBRE), el primer caso especifica cuál usar.

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

Respuesta aceptada:

Criterios/Requisitos del objetivo:

Al determinar si usar un valor absoluto o lógico (/usr/bin/env ) camino a un intérprete en un she-bang, hay (2) consideraciones clave:

a) El intérprete se puede encontrar en el sistema de destino

b) La versión correcta de intérprete se puede encontrar en el sistema de destino

Si ESTAMOS DE ACUERDO que “b) ” es deseable, también estamos de acuerdo en que :

c) Es preferible que nuestros scripts fallen en lugar de ejecutar usando una versión de intérprete incorrecta y potencialmente lograr resultados inconsistentes.

Si NO ESTAMOS DE ACUERDO que “b) ” importa, entonces cualquier intérprete encontrado será suficiente.

Pruebas:

Desde que usamos un lógico ruta- /usr/bin/env to the interpreter in the she-bang es la solución más extensible que permite que el mismo script se ejecute con éxito en los hosts de destino con diferentes rutas al mismo intérprete, lo probaremos, usando Python debido a su popularidad, para ver si cumple nuestros criterios.

  1. ¿/usr/bin/env vivir en una ubicación predecible y consistente en POPULAR (no “cada ") ¿Sistemas operativos? :
  • RHEL 7.5
  • Ubuntu 18.04
  • Raspbian 10 ("Buster")
  • OSX 10.15.02
  1. La siguiente secuencia de comandos de Python se ejecuta tanto dentro como fuera de los sobres virtuales (Pipenv utilizado) durante las pruebas:
    #!/usr/bin/env pythonX.x
    import sys
    print(sys.version)
    print('Hello, world!')
    
  2. El she-bang en el script fue alternado por el número de versión de Python deseado (todo instalado en el mismo host):
  • #!/usr/bin/env python2
  • #!/usr/bin/env python2.7
  • #!/usr/bin/env python3
  • #!/usr/bin/env python3.5
  • #!/usr/bin/env python3.6
  • #!/usr/bin/env python3.7
  1. Resultados esperados:que print(sys.version) =env pythonX.x . Cada vez ./test1.py se ejecutó usando una versión de Python instalada diferente, se imprimió la versión correcta especificada en el she-bang.

  2. Notas de prueba:

  • Las pruebas se limitaron exclusivamente a Python
  • Perl:como Python- DEBE vivir en /usr/bin según la FHS
  • No probé todas las combinaciones posibles en cada número posible de sistemas operativos Linuxy/Unixy y versiones de cada sistema operativo.
Relacionado:Linux:¿obtener capacidades de la unidad de CD/DVD cuando los dispositivos wodim no funcionan?

Conclusión:

Aunque es CIERTO que #!/usr/bin/env python utilizará la primera versión de Python que encuentre en la ruta del usuario, podemos moderar este comportamiento especificando un número de versión como #!/usr/bin/env pythonX.x . De hecho, a los desarrolladores no les importa qué intérprete se encuentra "primero “, todo lo que les importa es que su código se ejecute utilizando el intérprete especificado que saben que es compatible con su código para garantizar resultados consistentes, donde sea que viva en el sistema de archivos

En términos de portabilidad/flexibilidad, usando un lógico /usr/bin/env – en lugar de absoluto la ruta no solo cumple con los requisitos a), b) y c) de mis pruebas con diferentes versiones de Python , pero también tiene la ventaja de que la lógica difusa encuentra la misma versión del intérprete, incluso si viven en diferentes rutas en diferentes sistemas operativos. Y aunque LA MAYORÍA las distribuciones respetan el FHS, no todas lo hacen.

Entonces, ¿dónde fallará un script? si el binario vive en diferentes absolutos ruta luego especificada en shebang, el mismo script usando un lógico camino ÉXITO a medida que continúa hasta que encuentra una coincidencia, lo que ofrece una mayor confiabilidad y extensibilidad entre plataformas.


Linux
  1. /usr/bin Vs /usr/local/bin ¿En Linux?

  2. ¿Alguna razón para tener un Shebang apuntando a /bin/sh en lugar de /bin/bash?

  3. ¿Por qué /bin/sh apunta a /bin/dash y no a /bin/bash?

  4. ¿Por qué en algunos sistemas Linux, el sistema de archivos raíz aparece como /dev/root en lugar de /dev/<nodo de dispositivo real> en mtab?

  5. ¿Por qué los directorios /home, /usr, /var, etc. tienen todos el mismo número de inodo (2)?

¿Cuáles son los significados de /usr/sbin, /usr/local/sbin y /usr/local/bin?

¿Cuándo debo usar #!/bin/bash y cuándo #!/bin/sh?

¿Por qué poner otras cosas que no sean /home en una partición separada?

Diferencia entre /bin y /usr/bin

Se movió el contenido de /bin a /usr/bin, ¿es posible deshacerlo?

¿Deberían vivir los sitios web en /var/ o /usr/ según el uso recomendado?