La cabecera típica debe serPython cabecera guión
#!/usr/bin/env python
pero he encontrado a continuación también funciona cuando se ejecuta el script como $python ./my_script.py
#!/usr/bin/python
#!python
¿Cuál es la diferencia entre estos 2 cabeceras? ¿Cuál podría ser el problema para el segundo? Por favor, también discuta el caso de que el intérprete de Python esté en PATH o no. Gracias.
En primer lugar, cualquier momento de ejecutar una secuencia de comandos utilizando el intérprete de forma explícita, como en
$ python ./my_script.py
$ ksh ~/bin/redouble.sh
$ lua5.1 /usr/local/bin/osbf3
la línea #! siempre se ignora. La línea #! es una característica Unix de los scripts ejecutables únicamente, y puede verla documentada en su totalidad en man page for execve(2). Allí encontrará que la palabra siguiente a #! debe ser la ruta de acceso de un ejecutable válido. Así
#!/usr/bin/env python
ejecuta lo python está en los usuarios $PATH. Este formulario es resistente al intérprete de Python que se mueve, lo que lo hace algo más portátil, pero también significa que el usuario puede anular el intérprete estándar de Python al poner algo delante de él en $PATH. Dependiendo de tus objetivos, este comportamiento puede o no estar bien.
A continuación,
#!/usr/bin/python
se refiere al caso común que un intérprete de Python se instala en /usr/bin. Si está instalado en otro lugar, pierdes.Pero esta es una buena manera de asegurarse de que obtiene exactamente la versión que desee o bien nada en absoluto ("a prueba de parada" comportamiento), como en
#!/usr/bin/python2.5
Por último,
#!python
funciona sólo si hay un ejecutable python en el directorio actual cuando se ejecuta el script. No recomendado.
Sí, hay - pitón puede no estar en /usr/bin, pero por ejemplo en /usr/local/bin (BSD).
Al utilizar virtualenv, incluso puede ser algo así como ~/projects/env/bin/python
El Python ejecutable puede ser instalado en una ubicación distinta de/usr/bin, pero env está casi siempre presente en ese lugar por lo que usar /usr/bin/env es más portátil .
Desde la página del manual de env (GNU coreutils 6,10):
env - run a program in a modified environment
En teoría se podría utilizar env para restablecer el medio ambiente (la eliminación de muchas de las variables de entorno existentes) o añadir variables de entorno adicionales en la cabecera de la escritura . En términos prácticos, las dos versiones que mencionaste son idénticas. (Aunque otros han mencionado un buen punto:. Especificando python través env le deja en abstracto especificar python sin conocer su trayectoria)
El /usr/bin/env python se vuelve muy útil cuando sus scripts dependen de la configuración del entorno, por ejemplo, utilizando scripts que se basan en python virtualenv. Cada virtualenv tiene su propia versión de python binary que se requiere para agregar paquetes instalados en virtualenv a python path (sin tocar PYTHONPATH env).
Como más y más personas han comenzado a utilizar virtualenv para el desarrollo python prefieren usar /usr/bin/env python a menos que no desee que las personas usen su binario personalizado de python.
Nota: También debe comprender que existen posibles problemas de seguridad (en entornos multiusuario) cuando permite que las personas ejecuten sus scripts en sus entornos personalizados. Puede obtener algunas ideas del here.
me gustaría sugerir 3 cosas en el comienzo de su script:
primer lugar, como ya ha sido dicho entorno de uso:
#!/usr/bin/env python
En segundo lugar, cambiar la codificación:
# -*- coding: utf-8 -*-
En tercer lugar, establezca alguna cadena de documentación:
"""This is a awesome
python script!"""
Y seguro usaría " " (4 espacios) para ident.
encabezado final se verá así:
#!/usr/bin/env python
# -*- coding: utf-8 -*-
"""This is a awesome
python script!"""
mejores deseos y feliz de codificación.
ese encabezado se llama Shebang http://en.wikipedia.org/wiki/Shebang_%28Unix%29 – systempuntoout
FYI cuando ejecuta un script de la manera '$ python./My_script.py' (especificando' python' explícitamente), se ignora la línea shebang ('#!'). Solo tiene un efecto si ejecuta el script como un ejecutable, p. '$./my_script.py'. –
@David Zaslavsky: +1 Buena captura. –