que - ¿Qué significa en los scripts de Linux?#!/usr/bin/python-tt

#!/ usr bin env python que es (5)

Sé que al principio de los scripts .sh bash es

#!/bin/bash

que apunta al comando ejecutable de interpeter.

Pero durante la visualización de Google Python Class http://www.youtube.com/watch?v=tKTZoB2Vjuk noté que para python usan

#!/usr/bin/python -tt

. Navegando en Internet, también he encontrado estilos de esta notación:

#!/usr/local/bin/python

e incluso

#!/usr/bin/env python

Entonces, soy nuevo en Python y soy un usuario normal de Linux y tengo algunas preguntas sobre esta línea "mágica":

En primer lugar, ¿cuál es la forma correcta de esta línea? ¿y por qué?
¿Qué significa la tecla -tt en #! / Usr / bin / python -tt?
¿Qué programa está analizando esta línea en Linux?
¿Qué sintaxis de esta línea para cualquier script?
¿Por qué esta línea es tan necesaria si cada archivo tiene su extensión?
¿Y qué hay de eso en cada intérprete de computadora para algún tipo de guiones que se almacenarán en un lugar diferente que en otro? Y el script no se pudo ejecutar.

Es muy interesante para mi ¿Qué es esta línea? ¿Por qué esta línea? ¿Cómo escribir esta línea? ¿Por qué de tal manera? ...

#! / usr / bin / env python
emitir errores sobre el uso de la pestaña inconsistente
Núcleo
#! / path_to_the_interpreter o / usr / bin / env
* nix no comprueba la extensión en absoluto (excepto que algunos DE podrían hacerlo)
Es por eso que debes usar #! / Usr / bin / env

Más información en shebang

De la página del manual:

-t Emite una advertencia cuando un archivo de origen mezcla las pestañas y los espacios para la sangría de una manera que hace que dependa del valor de una pestaña expresada en espacios. Emitir un error cuando la opción se da dos veces.

La forma correcta de la línea es la que desea utilizar.
Es el intérprete que lee esta línea conocida como shebang . Si escribe un script de python con la primera línea como "#! / Usr / bin / python" y lo invoca usando bash, es el intérprete / bin / sh el que lee la primera línea e inicia el intérprete adecuado.
Es un shebang. La sintaxis de la función consiste en la secuencia de caracteres #, es decir, el signo de número y un carácter de signo de exclamación
Las extensiones de archivo no son relevantes en Linux en general . Puedes tener un script de Python que no tenga una extensión .py.

Por ej.

shadyabhi@archlinux ~ $ cat a print "Hello World" shadyabhi@archlinux ~ $ python2 a Hello World shadyabhi@archlinux ~ $

Incluso los shebangs solo son necesarios si desea iniciar un script usando $. / Script, ya que en este caso no mencionó el intérprete que desea usar.

Esto se llama un shebang. Le dice al sistema que debe pasar el archivo como un argumento al programa especificado en lugar de intentar ejecutarlo per se.

En primer lugar, ¿cuál es la forma correcta de esta línea? ¿y por qué?

La ruta correcta es donde esté instalado su intérprete de Python. Los argumentos ( -tt ) dependerán de lo que quieras. Algunas personas insisten en #!/usr/bin/env en caso de que el intérprete esté en algún otro lugar.

¿Qué significa la tecla -tt en #! / Usr / bin / python -tt?

No uso python, así que alguien más tendrá que responder esto.

Cuando lanzo un script en Linux (no el script exacto de Python), ¿qué programa analiza y usa esta línea? Considero que no es bash porque incluso para los scripts de bash esta línea es necesaria.

He oído (y estoy bastante seguro) que es el núcleo. Incluso si fuera bash, necesitaría la línea para decirle a bash que se supone que es un script que debe interpretar en lugar de pasar a otro programa. /usr/bin/env es un comando que busca en el PATH el argumento especificado y pasa el script a través del programa que encuentra.

¿Qué sintaxis de esta línea para cualquier script? ¿Y cuál es el nombre de interpeter que lo analiza?

La sintaxis es la misma que la línea de comando, #!command arguments , pero el command tiene que ser una ruta absoluta, no se busca el PATH .

¿Por qué esta línea es tan necesaria si cada archivo tiene su extensión?

Las extensiones no significan nada en * nix. Podría nombrar un script bash script.pl , script.exe o incluso un script sin una extensión. Si la secuencia de comandos tiene la línea shebang correcta, se pasa a través del intérprete correcto, de lo contrario, el núcleo intenta ejecutarlo como un ejecutable y falla. El sistema no sabe acerca de las extensiones. Son una convención para los usuarios, nada más.

¿Y qué hay de eso en cada intérprete de computadora para algún tipo de guiones que se almacenarán en un lugar diferente que en otro? Y el script no se pudo ejecutar.

Si entiendo esto correctamente, ¿está diciendo que diferentes sistemas / distribuciones mantienen a los intérpretes en diferentes lugares (por ejemplo, /usr/bin/python y /usr/local/bin/python ), y preguntan cómo sabe el sistema qué usar?
La respuesta es que usa el que está en la ruta absoluta que le diste. Esto es en realidad un pequeño problema con los scripts ejecutables, y la razón por la cual /usr/bin/env ha puesto de moda. Como dije, env busca en el PATH el intérprete correcto, por lo que siempre que su sistema tenga un /usr/bin/env , está configurado, no necesita buscar ni garantizar la ubicación del intérprete.

Las diferentes rutas son a donde se ha instalado el intérprete de python. Diferentes tipos de Linux lo instalan en diferentes lugares.

Linux no se preocupa por las extensiones es una cosa de Windows.

La sesión de bash usa la línea para llamar al intérprete correcto para el script que está ejecutando.

Los diferentes lugares donde se almacenan, llaman y usan los archivos se basan en lugares definidos donde deben estar los archivos y se encuentran ubicados por software. Dev para dispositivos, hogar para el área almacenada por el usuario, bin para programas. Pero a medida que pasa el tiempo, los diferentes sistemas requieren diferentes ubicaciones.

Yo sugeriría obtener un libro sobre Linux / Unix y aprender los conceptos básicos del sistema de archivos. Ayuda mucho.

Pregunta # 1) La línea se llama shebang, y no hay una forma correcta que funcione universalmente. p.ej

#!python #!/usr/bin/python #!/usr/local/bin/python #!/usr/bin/python -t

Todas las formas son válidas / aceptables, pero pueden no funcionar en todos los sistemas:

#!python solo funcionará si el ejecutable de python está en algún lugar del PATH de tu shell

#!/usr/bin/python solo funciona si el binario de python está realmente en / usr / bin

#!/usr/local/bin/python también funciona si python está en / usr / local / bin

Pregunta 2)

#!/usr/bin/python -tt está pasando la opción -tt a python, como si lo hubieras hecho:

$ python -t somescript.py

en el indicador de shell. Puede pasar argumentos de línea de comando arbitrarios al intérprete en la línea shebang.

Pregunta 3)

La línea es interpretada por el núcleo del sistema operativo y el shell que está utilizando actualmente. Las cosas después de la #! simplemente le dice al sistema operativo qué programa debe activarse para "ejecutar" el resto del script.

Pregunta # 4)

La sintaxis del script depende del idioma que estés usando. Por ejemplo, un script de shell PHP debe tomar la forma de

#!/usr/bin/php <?php ... php code here ...

Una secuencia de comandos de Perl #!/usr/bin/perl debe usar la sintaxis de Perl, etc ... Si coloca el código PHP con un Perl Shebang, solo tendrá la secuencia de comandos de Perl barf con errores de sintaxis, ya que el código PHP NO es perl código

Pregunta # 5)

Los shebangs son para sistemas Unix, donde las extensiones de archivo nunca se usaron realmente para identificar tipos de archivos para el sistema operativo. Un archivo .c se entendió como un archivo de código fuente en lenguaje C, pero eso es simplemente una convención. Podría poner un script de shell Bash en un archivo .c , hacer que sea ejecutable, y con el #!/bin/bash shebang, se ejecutaría como un script Bash.

Determinar los tipos de ejecutables por extensión de archivo es más que una cosa de Windows.

Pregunta # 6)

Eso se remonta a la pregunta # 1: si el shebang afirma que el intérprete se encuentra en una OTRA Ruta que no es donde está, este script en particular no puede ejecutarse hasta que se arregle el shebang, o se mueva el intérprete. Shebangs son muy útiles, pero no infalibles.

Afortunadamente, la mayoría de los intérpretes están instalados en ubicaciones bastante estándar en estos días, por lo que sería algo inusual encontrar Perl instalado en /some/wonky/weird/path lugar de /usr/bin