¿Por qué la gente escribe #! / Usr / bin / env python en la primera línea de un script de Python?

1171

Me parece que los archivos se ejecutan igual sin esa línea.

6
  • 1
    La respuesta a continuación que dice que es solo una línea de comentario. No siempre es así. Tengo un "¡Hola, mundo!" Script CGI (.py) que solo se ejecutará y mostrará la página web con #!/usr/bin/env pythonen la parte superior. Chakotay 9/11/2013 a las 22:56
  • 2
    posible duplicado de ¿Cuál es la diferencia entre estos dos shebangs pitónfuad 18 feb 2014 a las 12:15
  • Pueden ejecutarse, pero no en el entorno previstoNicholas Hamilton 28 de julio de 2014 a las 9:09
  • 1
    ¿Cuál es el efecto de esta línea en el virtualenv? Digamos que mi entorno virtual está usando 3.7.7 y python global tiene 2.7 (esto es lo que obtengo cuando uso python -V fuera de virtual), cuando me divierto con el archivo shabanged en el entorno virtual, ¿se refiere a python2.7? intérprete de global? santhosh kumar 10/07/20 a las 12:28
  • Eliminé "shebang" del título ya que originalmente no estaba allí y su adición al título hace que toda la pregunta y sus respuestas sean absurdas ("P: ¿Por qué agregar un shebang?" - "A: Esto se llama un shebang " … no). Konrad Rudolph 12/10/20 a las 16:51
1166

Si tiene varias versiones de Python instaladas, /usr/bin/envse asegurará de que el intérprete utilizado sea el primero en su entorno $PATH. La alternativa sería codificar algo como #!/usr/bin/python; eso está bien, pero menos flexible.

En Unix, un archivo ejecutable que está destinado a ser interpretado puede indicar qué intérprete usar al tener un #!al comienzo de la primera línea, seguido del intérprete (y cualquier indicador que pueda necesitar).

Si está hablando de otras plataformas, por supuesto, esta regla no se aplica (pero esa "línea shebang" no hace daño y le ayudará si alguna vez copia ese script en una plataforma con una base Unix, como Linux, Mac , etc.).

14
  • 298
    Solo para agregar: esto se aplica cuando lo ejecuta en Unix haciéndolo ejecutable ( chmod +x myscript.py) y luego ejecutándolo directamente:, en ./myscript.pylugar de solo python myscript.py. Craig McQueen 12 de marzo de 2010 a las 2:48
  • 30
    el uso envofrece la máxima flexibilidad en el sentido de que el usuario puede seleccionar el intérprete a utilizar cambiando la RUTA. Sin embargo, a menudo esta flexibilidad no es necesaria y la desventaja es que Linux, por ejemplo, no puede usar el nombre del script para el nombre del proceso psy vuelve a "python". Al empaquetar aplicaciones de Python para distribuciones, por ejemplo, recomendaría no usar env. pixelbeat 12/03/10 a las 13:26
  • 9
    pyEl lanzador puede usar la línea shebang en Windows. Está incluido en Python 3.3 o se puede instalar de forma independiente . jfs 17 de enero de 2013 a las 0:35
  • 6
    Una advertencia importante, el valor de retorno de env eventualmente caduca. Lo cual es poco probable que le afecte si está ejecutando procesos de corta duración. Sin embargo, he tenido procesos que mueren con el mensaje /usr/bin/env: Key has expireddespués de muchas horas. malaverdiere 29/12/2017 a las 20:01
  • 7
    @malaverdiere ¿puede vincular a algún recurso que explique este comportamiento de vencimiento? No puedo encontrarlos. Michael 26 oct 2018 a las 4:36
286

Eso se llama la línea shebang . Como explica la entrada de Wikipedia :

In computing, a shebang (also called a hashbang, hashpling, pound bang, or crunchbang) refers to the characters "#!" when they are the first two characters in an interpreter directive as the first line of a text file. In a Unix-like operating system, the program loader takes the presence of these two characters as an indication that the file is a script, and tries to execute that script using the interpreter specified by the rest of the first line in the file.

Consulte también la entrada de preguntas frecuentes de Unix .

Incluso en Windows, donde la línea shebang no determina el intérprete que se ejecutará, puede pasar opciones al intérprete especificándolas en la línea shebang. Encuentro útil mantener una línea shebang genérica en scripts únicos (como los que escribo cuando respondo preguntas sobre SO), para poder probarlos rápidamente tanto en Windows como en ArchLinux .

La utilidad env le permite invocar un comando en la ruta:

The first remaining argument specifies the program name to invoke; it is searched for according to the PATH environment variable. Any remaining arguments are passed as arguments to that program.

7
  • 1
    @Arafangion probablemente encontrará útil esta pregunta . TL; DR: symbolhound.comulidtko 8 de enero de 2015 a las 12:54
  • 2
    "Incluso en Windows, donde la línea shebang no determina el intérprete que se ejecutará, puede pasar opciones al intérprete especificándolas en la línea shebang". Eso es simplemente falso; si sucede tal cosa, es porque el propio intérprete está procesando la línea shebang. Si el intérprete no tiene un reconocimiento especial para las líneas shebang, entonces no sucede tal cosa. Windows no hace nada con las líneas shebang ". Lo que puede estar describiendo en este caso es el lanzador de Python: python.org/dev/peps/pep-0397 .Kaz 24 de mayo de 2019 a las 22:33
  • Windows no tiene ninguna disposición para hacer un archivo ".py" ejecutable en absoluto. Los archivos de Python aparecen como ejecutables desde el shell del Explorador a través de una asociación del .pysufijo como un documento a una aplicación. Si esa aplicación es el pylauncher específico de Python, entonces obtiene el procesamiento de hash bang. Eso es todo. Kaz 24 de mayo de 2019 a las 22:36
  • 1
    @Shuzheng Lea atentamente la oración. No dice ni lo que tú ni Kaz creen que dice. Por ejemplo, perlen Windows no le importa ni un ápice que no haya /usr/bin/perl, pero prestará atención a las opciones que se le pasen. Sinan Ünür 14 nov 2019 a las 1:08
  • 1
    @Shuzheng _Por favor, lea la oración con atención. No dice ni lo que tú ni Kaz creen que diceSinan Ünür 21/11/19 a las 1:58
160

Ampliando un poco las otras respuestas, aquí hay un pequeño ejemplo de cómo sus scripts de línea de comando pueden meterse en problemas por el uso imprudente de las /usr/bin/envlíneas shebang:

$ /usr/local/bin/python -V
Python 2.6.4
$ /usr/bin/python -V
Python 2.5.1
$ cat my_script.py 
#!/usr/bin/env python
import json
print "hello, json"
$ PATH=/usr/local/bin:/usr/bin
$ ./my_script.py 
hello, json
$ PATH=/usr/bin:/usr/local/bin
$ ./my_script.py 
Traceback (most recent call last):
  File "./my_script.py", line 2, in <module>
    import json
ImportError: No module named json

El módulo json no existe en Python 2.5.

Una forma de protegerse contra ese tipo de problema es usar los nombres de comandos de Python versionados que normalmente se instalan con la mayoría de Pythons:

$ cat my_script.py 
#!/usr/bin/env python2.6
import json
print "hello, json"

Si solo necesita distinguir entre Python 2.xy Python 3.x, las versiones recientes de Python 3 también proporcionan un python3nombre:

$ cat my_script.py 
#!/usr/bin/env python3
import json
print("hello, json")
2
  • 28
    Hmm, eso no es lo que obtuve de esa publicación. glenn jackman 12/03/10 a las 16:58
  • 1
    Diferencia entre local y global. Si which pythonvuelve /usr/bin/python, una ruta de directorio local podría estar codificado: #!/usr/bin/python. Pero eso es menos flexible que lo #!/usr/bin/env pythonque tiene una aplicación global. noobninja 25/07/2016 a las 15:48
90

Para ejecutar el script de Python, necesitamos decirle al shell tres cosas:

  1. Que el archivo es un script
  2. Qué intérprete queremos que ejecute el script
  3. El camino de dicho intérprete

El shebang #!cumple (1.). El shebang comienza con a #porque el #personaje es un marcador de comentario en muchos lenguajes de programación. Por lo tanto, el intérprete ignora automáticamente el contenido de la línea shebang.

El envcomando cumple (2.) y (3.). Para citar "grawity",

A common use of the env command is to launch interpreters, by making use of the fact that env will search $PATH for the command it is told to launch. Since the shebang line requires an absolute path to be specified, and since the location of various interpreters (perl, bash, python) may vary a lot, it is common to use:

#!/usr/bin/env perl  instead of trying to guess whether it is /bin/perl, /usr/bin/perl, /usr/local/bin/perl, /usr/local/pkg/perl, /fileserver/usr/bin/perl, or /home/MrDaniel/usr/bin/perl on the user's system...

On the other hand, env is almost always in /usr/bin/env. (Except in cases when it isn't; some systems might use /bin/env, but that's a fairly rare occassion and only happens on non-Linux systems.)

1
  • 1
    "grawity" donde? Pacerier 16 de agosto de 2017 a las 0:44
61

La execllamada al sistema del kernel de Linux comprende shebangs ( #!) de forma nativa

Cuando lo haces en bash:

./something

en Linux, esto llama a la execllamada al sistema con la ruta ./something.

Esta línea del kernel se llama en el archivo pasado a exec: https://github.com/torvalds/linux/blob/v4.8/fs/binfmt_script.c#L25

if ((bprm->buf[0] != '#') || (bprm->buf[1] != '!'))

Lee los primeros bytes del archivo y los compara con #!.

Si la comparación es verdadera, entonces el resto de la línea es analizada por el kernel de Linux, que realiza otra execllamada con:

  • ejecutable: /usr/bin/env
  • primer argumento: python
  • segundo argumento: ruta del script

por lo tanto equivalente a:

/usr/bin/env python /path/to/script.py

enves un ejecutable que busca, PATHpor ejemplo /usr/bin/python, encontrar , y finalmente llama:

/usr/bin/python /path/to/script.py

El intérprete de Python ve la #!línea en el archivo, pero #es el carácter de comentario en Python, por lo que esa línea simplemente se ignora como un comentario regular.

Y sí, puedes hacer un bucle infinito con:

printf '#!/a\n' | sudo tee /a
sudo chmod +x /a
/a

Bash reconoce el error:

-bash: /a: /a: bad interpreter: Too many levels of symbolic links

#! resulta ser legible por humanos, pero no es necesario.

Si el archivo comenzaba con bytes diferentes, la execllamada al sistema usaría un controlador diferente. El otro controlador integrado más importante es para archivos ejecutables ELF: https://github.com/torvalds/linux/blob/v4.8/fs/binfmt_elf.c#L1305 que busca bytes 7f 45 4c 46(que también son humanos legible para .ELF). Confirmemos eso leyendo los 4 primeros bytes de /bin/ls, que es un ejecutable ELF:

head -c 4 "$(which ls)" | hd 

producción:

00000000  7f 45 4c 46                                       |.ELF|
00000004                                                                 

Entonces, cuando el kernel ve esos bytes, toma el archivo ELF, lo coloca en la memoria correctamente e inicia un nuevo proceso con él. Consulte también: ¿Cómo obtiene el kernel un archivo binario ejecutable que se ejecuta en Linux?

Finalmente, puede agregar sus propios manejadores de shebang con el binfmt_miscmecanismo. Por ejemplo, puede agregar un controlador personalizado para .jararchivos . Este mecanismo incluso admite controladores por extensión de archivo. Otra aplicación es ejecutar de forma transparente ejecutables de una arquitectura diferente con QEMU .

Sin embargo , no creo que POSIX especifique shebangs: https://unix.stackexchange.com/a/346214/32558 , aunque menciona en las secciones de justificación, y en la forma "si el sistema admite scripts ejecutables, algo puede ocurrir". Sin embargo, macOS y FreeBSD también parecen implementarlo.

PATH motivación de búsqueda

Probablemente, una gran motivación para la existencia de shebangs es el hecho de que en Linux, a menudo queremos ejecutar comandos desde PATH:

basename-of-command

en lugar de:

/full/path/to/basename-of-command

Pero entonces, sin el mecanismo shebang, ¿cómo sabría Linux cómo lanzar cada tipo de archivo?

Codificación de la extensión en comandos:

 basename-of-command.py

o implementar la búsqueda PATH en cada intérprete:

python basename-of-command

sería una posibilidad, pero esto tiene el problema principal de que todo se rompe si alguna vez decidimos refactorizar el comando en otro idioma.

Shebangs resuelve este problema maravillosamente.

Caso de uso principal de env: pyenvy otros administradores de versiones

Un caso de uso importante de por qué debería usar en #!/usr/bin/env pythonlugar de solo /usr/bin/pythones el de los administradores de versiones con pyenv.

pyenv le permite instalar fácilmente múltiples versiones de Python en una sola máquina, para poder reproducir mejor otros proyectos sin virtualización.

Luego, administra la versión de Python "actual" estableciendo su orden en la RUTA: por ejemplo, como se muestra en apt-get install para diferentes versiones de Python, una Python administrada por pyenv podría ubicarse en:

/home/ciro/.pyenv/shims/python

tan lejos de /usr/bin/python, que algunos sistemas podrían manejar a través de update-alternativesenlaces simbólicos .

48

Quizás tu pregunta sea en este sentido:

Si quieres usar: $python myscript.py

No necesitas esa línea en absoluto. El sistema llamará a Python y luego el intérprete de Python ejecutará su script.

Pero si tiene la intención de usar: $./myscript.py

Llamándolo directamente como un programa normal o un script bash, necesita escribir esa línea para especificar al sistema qué programa usa para ejecutarlo (y también hacerlo ejecutable con chmod 755)

1
  • o puede escribir python3 myscript.pyvijay shanker 20/06/2017 a las 18:25
40

Técnicamente, en Python, esto es solo una línea de comentario.

Esta línea solo se usa si ejecuta el script py desde el shell (desde la línea de comando). Esto se conoce como el " Shebang !" , y se usa en varias situaciones, no solo con scripts de Python.

Aquí, le indica al shell que inicie una versión específica de Python (para encargarse del resto del archivo.

1
  • 1
    El shebang es un concepto de Unix. Vale la pena mencionar que también funciona en Windows si ha instalado el lanzador de Python py.exe . Esto es parte de una instalación estándar de Python. florisla 6 de mayo de 2020 a las 7:27
39

La razón principal para hacer esto es hacer que el script sea portátil en todos los entornos del sistema operativo.

Por ejemplo, en mingw, los scripts de Python usan:

#!/c/python3k/python 

y bajo la distribución GNU / Linux es:

#!/usr/local/bin/python 

o

#!/usr/bin/python

y bajo el mejor sistema sw / hw Unix comercial de todos (OS / X), es:

#!/Applications/MacPython 2.5/python

o en FreeBSD:

#!/usr/local/bin/python

Sin embargo, todas estas diferencias pueden hacer que el script sea portátil en todos mediante el uso de:

#!/usr/bin/env python
3
  • 2
    En MacOSX, también lo es /usr/bin/python. Bajo Linux, el Python instalado por el sistema también es casi seguro /usr/bin/python(nunca he visto nada más y no tendría sentido). Tenga en cuenta que puede haber sistemas que no tengan /usr/bin/env. Albert 28/11/12 a las 0:37
  • 2
    Si está en OSX y usa Homebrew y sigue sus instrucciones de instalación predeterminadas, estará en #! / Usr / local / bin / pythonWill 13 feb.14 a las 17:17
  • Actualización para el año 2018: Bare pythonno es tan portátil, es el intérprete de Python predeterminado de distribución. Arch Linux utiliza Python 3 de forma predeterminada durante mucho tiempo y es posible que las distribuciones también lo estén pensando porque Python 2 solo es compatible hasta 2020.mati865 29 de junio de 2018 a las 8:35
23

Probablemente tenga sentido enfatizar una cosa que la mayoría ha pasado por alto, lo que puede impedir la comprensión inmediata. Cuando escribe pythonterminal, normalmente no proporciona una ruta completa. En cambio, el ejecutable se busca en PATHla variable de entorno. A su vez, cuando desee ejecutar un programa Python directamente, /path/to/app.pyuno debe decirle al intérprete qué intérprete usar (a través del hashbang , lo que los otros contribuyentes están explicando arriba).

Hashbang espera una ruta completa hacia un intérprete. Por lo tanto, para ejecutar su programa Python directamente, debe proporcionar la ruta completa al binario de Python, que varía significativamente, especialmente considerando el uso de virtualenv . Para abordar la portabilidad /usr/bin/envse utiliza el truco con . Este último está destinado originalmente a alterar el entorno en el lugar y ejecutar un comando en él. Cuando no se proporciona ninguna alteración, ejecuta el comando en el entorno actual, lo que efectivamente da como resultado la misma PATHbúsqueda que hace el truco.

Fuente de unix stackexchange

17

Esta es una convención de shell que le dice al shell qué programa puede ejecutar el script.

#!/usr/bin/env python

se resuelve en una ruta al binario de Python.

13

Es la forma recomendada, propuesta en la documentación:

2.2.2. Executable Python Scripts

On BSD’ish Unix systems, Python scripts can be made directly executable, like shell scripts, by putting the line

#! /usr/bin/env python3.2

de http://docs.python.org/py3k/tutorial/interpreter.html#executable-python-scripts

0
11

Puedes probar este problema usando virtualenv

Aquí está test.py

#! /usr/bin/env python
import sys
print(sys.version)

Crea entornos virtuales

virtualenv test2.6 -p /usr/bin/python2.6
virtualenv test2.7 -p /usr/bin/python2.7

active cada entorno y luego verifique las diferencias

echo $PATH
./test.py
11

Solo especifica qué intérprete desea utilizar. Para entender esto, cree un archivo a través de la terminal haciendo touch test.py, luego escriba en ese archivo lo siguiente:

#!/usr/bin/env python3
print "test"

y hazlo chmod +x test.pypara que tu script sea ejecutable. Después de esto, cuando lo haga ./test.py, debería recibir un error que diga:

  File "./test.py", line 2
    print "test"
               ^
SyntaxError: Missing parentheses in call to 'print'

porque python3 no suministra al operador de impresión.

Ahora siga adelante y cambie la primera línea de su código a:

#!/usr/bin/env python2

y funcionará, imprimiendo testen stdout, porque python2 admite el operador de impresión. Entonces, ahora ha aprendido a cambiar entre intérpretes de guiones.

10

It seems to me like the files run the same without that line.

Si es así, ¿quizás esté ejecutando el programa Python en Windows? Windows no usa esa línea; en su lugar, usa la extensión del nombre del archivo para ejecutar el programa asociado con la extensión del archivo.

Sin embargo, en 2011, se desarrolló un "lanzador de Python" que (hasta cierto punto) imita este comportamiento de Linux para Windows. Esto se limita solo a elegir qué intérprete de Python se ejecuta, por ejemplo, para seleccionar entre Python 2 y Python 3 en un sistema donde ambos están instalados. El lanzador se instala opcionalmente como py.exeen la instalación de Python y se puede asociar con .pyarchivos para que el lanzador verifique esa línea y, a su vez, ejecute la versión especificada del intérprete de Python.

2
  • 7
    También podría estar usando $ python myscript.py. Sinan Ünür 12 de marzo de 2010 a las 0:02
  • Cometí el error al no tener la línea y usé python script.py, y un día simplemente hice ./myscript.py y todo dejó de funcionar, luego me di cuenta de que el sistema está mirando el archivo como un script de shell en lugar de un script de Python. Guagua 23/04/2014 a las 21:32
8

Esto se entiende más como información histórica que como una respuesta "real".

Recuerde que en su día tenía MUCHOS sistemas operativos tipo Unix, cuyos diseñadores tenían su propia noción de dónde colocar las cosas, y a veces no incluían Python, Perl, Bash o muchas otras cosas de GNU / Open Source en absoluto. .

Esto fue incluso cierto para diferentes distribuciones de Linux. En Linux, antes de FHS [1], es posible que tenga python en / usr / bin / o / usr / local / bin /. O puede que no se haya instalado, por lo que creó el suyo y lo puso en ~ / bin

Solaris fue lo peor en el que trabajé, en parte debido a la transición de Berkeley Unix a System V.Podría terminar con cosas en / usr /, / usr / local /, / usr / ucb, / opt / etc. por algunos caminos realmente largos. Tengo recuerdos de las cosas de Sunfreeware.com instalando cada paquete en su propio directorio, pero no recuerdo si enlazó simbólicamente los binarios en / usr / bin o no.

Ah, ya veces / usr / bin estaba en un servidor NFS [2].

Así que la envutilidad se desarrolló para solucionar este problema.

Entonces podías escribir #!/bin/env interpretery siempre que la ruta fuera la correcta, las cosas tenían una probabilidad razonable de funcionar. Por supuesto, razonable significaba (para Python y Perl) que también había establecido las variables ambientales apropiadas. Para bash / ksh / zsh simplemente funcionó.

Esto era importante porque la gente pasaba scripts de shell (como perl y python) y si codificaba / usr / bin / python en su estación de trabajo Red Hat Linux, se estropearía en un SGI ... bueno, no , Creo que IRIX puso a Python en el lugar correcto. Pero en una estación Sparc puede que no funcione en absoluto.

Extraño mi estación de sparc. Pero no mucho. Ok, ahora me tienes dando vueltas en E-Bay. Bastages.

[1] Estándar de jerarquía del sistema de archivos. https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard

[2] Sí, ya veces la gente todavía hace cosas así. Y no, no me puse ni un nabo NI una cebolla en mi cinturón.

5

Si está ejecutando su secuencia de comandos en un entorno virtual, digamos venv, entonces ejecutar which pythonmientras trabaja venvmostrará la ruta al intérprete de Python:

~/Envs/venv/bin/python

Tenga en cuenta que el nombre del entorno virtual está incrustado en la ruta al intérprete de Python. Por lo tanto, codificar esta ruta en su secuencia de comandos causará dos problemas:

  • Si carga el script en un repositorio, está obligando a otros usuarios a tener el mismo nombre de entorno virtual . Esto es si identifican el problema primero.
  • No podrá ejecutar el script en varios entornos virtuales incluso si tuviera todos los paquetes necesarios en otros entornos virtuales.

Por lo tanto, para agregar a la respuesta de Jonathan , el asunto ideal es #!/usr/bin/env python, no solo para la portabilidad entre sistemas operativos, sino también para la portabilidad en entornos virtuales.

5

La línea #!/bin/bash/python3o #!/bin/bash/pythonespecifica qué compilador de Python usar. Es posible que tenga instaladas varias versiones de Python. Por ejemplo,
a.py:

#!/bin/bash/python3
print("Hello World")

es un script de python3 y
b.py:

#!/bin/bash/python
print "Hello World"

es una secuencia de comandos de Python 2.x
Para ejecutar este archivo ./a.pyo ./b.pyse utiliza, debe otorgar privilegios de ejecución de archivos de antemano, de lo contrario, la ejecución dará lugar a un Permission deniederror.
Por dar permiso de ejecución,

chmod +x a.py
1
  • / bin / bash / python? Eso me confunde. Kevin C 19 de agosto a las 11:41
3

Teniendo en cuenta los problemas de portabilidad entre python2y python3, siempre debe especificar cualquiera de las versiones a menos que su programa sea compatible con ambas.

Algunas distribuciones se están enviando con pythonenlaces simbólicos python3desde hace un tiempo, no confíe en pythonser python2.

Esto es enfatizado por PEP 394 :

In order to tolerate differences across platforms, all new code that needs to invoke the Python interpreter should not specify python, but rather should specify either python2 or python3 (or the more specific python2.x and python3.x versions; see the Migration Notes). This distinction should be made in shebangs, when invoking from a shell script, when invoking via the system() call, or when invoking in any other context.

3

Le dice al intérprete con qué versión de Python ejecutar el programa cuando tiene varias versiones de Python.

2

Le permite seleccionar el ejecutable que desea utilizar; lo cual es muy útil si quizás tiene varias instalaciones de Python y diferentes módulos en cada una y desea elegir. p.ej

#!/bin/sh
#
# Choose the python we need. Explanation:
# a) '''\' translates to \ in shell, and starts a python multi-line string
# b) "" strings are treated as string concat by python, shell ignores them
# c) "true" command ignores its arguments
# c) exit before the ending ''' so the shell reads no further
# d) reset set docstrings to ignore the multiline comment code
#
"true" '''\'
PREFERRED_PYTHON=/Library/Frameworks/Python.framework/Versions/2.7/bin/python
ALTERNATIVE_PYTHON=/Library/Frameworks/Python.framework/Versions/3.6/bin/python3
FALLBACK_PYTHON=python3

if [ -x $PREFERRED_PYTHON ]; then
    echo Using preferred python $ALTERNATIVE_PYTHON
    exec $PREFERRED_PYTHON "$0" "[email protected]"
elif [ -x $ALTERNATIVE_PYTHON ]; then
    echo Using alternative python $ALTERNATIVE_PYTHON
    exec $ALTERNATIVE_PYTHON "$0" "[email protected]"
else
    echo Using fallback python $FALLBACK_PYTHON
    exec python3 "$0" "[email protected]"
fi
exit 127
'''

__doc__ = """What this file does"""
print(__doc__)
import platform
print(platform.python_version())
0
-10

¡Esto le dice al script dónde está el directorio de Python!

#! /usr/bin/env python