En informática , un shebang es la secuencia de caracteres #!, que consta de los caracteres signo de número (también conocido como sostenido o almohadilla ) y signo de exclamación (también conocido como bang ), al comienzo de un script . También se le llama sostenido-exclamación , sha-bang , [1] [2] hashbang , [3] [4] libra-bang , [5] [6] o hash-pling . [7]
Cuando se utiliza un archivo de texto con un shebang como si fuera un ejecutable en un sistema operativo tipo Unix , el mecanismo de carga del programa analiza el resto de la línea inicial del archivo como una directiva de interpretación . El cargador ejecuta el programa intérprete especificado , pasándole como argumento la ruta que se utilizó inicialmente al intentar ejecutar el script, de modo que el programa pueda utilizar el archivo como datos de entrada. [8] Por ejemplo, si un script se nombra con la ruta path /to/script y comienza con la línea #!/bin/sh, entonces se le indica al cargador del programa que ejecute el programa /bin/sh , pasando path/to/script como primer argumento.
El intérprete suele ignorar la línea shebang, porque el carácter "#" es un marcador de comentario en muchos lenguajes de programación; algunos intérpretes de lenguajes que no usan el signo almohadilla para comenzar comentarios aún pueden ignorar la línea shebang en reconocimiento de su propósito. [9]
La forma de una directiva de interpretación shebang es la siguiente: [8]
#! intérprete [ arg-opcional ]
donde interpreter es una ruta a un programa ejecutable. El espacio entre #! e interpreter es opcional. Puede haber cualquier cantidad de espacios o tabulaciones antes o después de interpreter . El argumento opcional incluirá cualquier espacio adicional hasta el final de la línea.
En Linux , el archivo especificado por el intérprete se puede ejecutar si tiene los derechos de ejecución y es uno de los siguientes:
En Linux y Minix , un intérprete también puede ser un script. Una cadena de shebangs y wrappers produce un archivo directamente ejecutable que obtiene los scripts encontrados como parámetros en orden inverso. Por ejemplo, si el archivo /bin/A es un archivo ejecutable en formato ELF , el archivo /bin/B contiene el shebang #!/bin/A optparamy el archivo /bin/C contiene el shebang #!/bin/B, entonces la ejecución del archivo /bin/C se resuelve en /bin/B /bin/C, que finalmente se resuelve en /bin/A optparam /bin/B /bin/C.
En los sistemas operativos derivados de Solaris y Darwin (como macOS ), el archivo especificado por el intérprete debe ser un binario ejecutable y no puede ser un script. [10]
Algunas líneas típicas del shebang:
#!/bin/sh– Ejecute el archivo utilizando el shell Bourne o un shell compatible, que se supone que está en el directorio /bin#!/bin/bash– Ejecutar el archivo usando el shell Bash#!/usr/bin/pwsh– Ejecutar el archivo usando PowerShell#!/usr/bin/env python3– Ejecútelo con un intérprete de Python , utilizando la ruta de búsqueda del programa env para encontrarlo#!/bin/false– No hace nada, pero devuelve un estado de salida distinto de cero , lo que indica un error. Se utiliza para evitar la ejecución independiente de un archivo de script destinado a ejecutarse en un contexto específico, como por ejemplo mediante el .comando desde sh/bash, sourcedesde csh/tcsh o como un archivo .profile, .cshrc o .login.Las líneas shebang pueden incluir opciones específicas que se pasan al intérprete. Sin embargo, las implementaciones varían en el comportamiento de análisis de las opciones; para la portabilidad, solo se debe especificar una opción sin ningún espacio en blanco incrustado. [11] A continuación se encuentran más pautas de portabilidad.
Las directivas de intérprete permiten utilizar scripts y archivos de datos como comandos, ocultando los detalles de su implementación a los usuarios y otros programas, al eliminar la necesidad de anteponer el intérprete a los scripts en la línea de comandos.
Por ejemplo, considere un script que tenga la línea inicial #!/bin/sh -x. Se lo puede invocar simplemente proporcionando su ruta de archivo, como some/path/to/foo, [12] y algunos parámetros, como bary baz:
algún/camino/a/foo bar baz
En este caso /bin/shse invoca en su lugar, con los parámetros -x, some/path/to/foo, bar, y baz, como si el comando original hubiera sido
/bin/sh -x alguna/ruta/a/foo bar baz
La mayoría de los intérpretes ponen a disposición del script cualquier argumento adicional. Si /bin/shes un shell compatible con POSIX , entonces bary bazse presentan al script como la matriz de parámetros posicionales "$@"y, de forma individual, como parámetros "$1"y "$2"respectivamente.
Debido a que el # inicial es el carácter que se utiliza para introducir comentarios en el lenguaje de shell POSIX (y en los lenguajes que entienden muchos otros intérpretes), el intérprete ignora toda la línea shebang. Sin embargo, es decisión del intérprete ignorar la línea shebang, y no todos lo hacen; por lo tanto, un script que consta de las dos líneas siguientes simplemente muestra ambas líneas cuando se ejecuta:
#!/bin/gato¡Hola Mundo!
En comparación con el uso de listas de asociación globales entre extensiones de archivos y aplicaciones de interpretación, el método de directiva de intérprete permite a los usuarios utilizar intérpretes no conocidos a nivel de sistema global y sin derechos de administrador. También permite la selección específica de intérpretes, sin sobrecargar el espacio de nombres de extensión de nombre de archivo (donde una extensión de archivo se refiere a más de un tipo de archivo), y permite cambiar el lenguaje de implementación de un script sin cambiar su sintaxis de invocación por otros programas. Los invocadores del script no necesitan saber cuál es el lenguaje de implementación, ya que el script en sí es responsable de especificar el intérprete a utilizar.
Los shebangs deben especificar rutas absolutas (o rutas relativas al directorio de trabajo actual) a los ejecutables del sistema; esto puede causar problemas en sistemas que tienen un diseño de sistema de archivos no estándar. Incluso cuando los sistemas tienen rutas bastante estándar, es muy posible que las variantes del mismo sistema operativo tengan diferentes ubicaciones para el intérprete deseado. Python , por ejemplo, podría estar en /usr/bin/python3 , /usr/local/bin/python3 o incluso algo como /home/username/bin/python3 si lo instala un usuario común.
Existe un problema similar para el shell POSIX , ya que POSIX solo requería que su nombre fuera sh , pero no exigía una ruta. Un valor común es /bin/sh , pero algunos sistemas como Solaris tienen el shell compatible con POSIX en /usr/xpg4/bin/sh . [13] En muchos sistemas Linux , /bin/sh es un enlace duro o simbólico a /bin/bash , el shell Bourne Again (BASH). El uso de una sintaxis específica de bash mientras se mantiene un shebang que apunta a sh tampoco es portable. [14]
Por este motivo, a veces es necesario editar la línea shebang después de copiar un script de una computadora a otra, ya que la ruta que se codificó en el script puede no ser aplicable en una nueva máquina, dependiendo de la consistencia en la convención anterior de ubicación del intérprete. Por este motivo y debido a que POSIX no estandariza los nombres de ruta, POSIX no estandariza la característica. [15] La herramienta GNU Autoconf puede probar la compatibilidad del sistema con la macro AC_SYS_INTERPRETER. [16]
A menudo, el programa /usr/bin/env se puede utilizar para evitar esta limitación introduciendo un nivel de indirección . va seguido de /usr/bin/env , seguido del comando deseado sin la ruta completa, como en este ejemplo:#!
#!/usr/bin/envsh
Esto funciona principalmente porque la ruta /usr/bin/env se usa comúnmente para la utilidad env e invoca el primer sh que se encuentra en el $PATH del usuario , normalmente /bin/sh .
Este ejemplo en particular (que utiliza sh ) tiene una utilidad limitada: ni /bin/sh ni /usr/bin/env son universales, y hay una cantidad similar de dispositivos que carecen de cada uno de ellos. En términos más generales, el uso de #!/usr/bin/env para cualquier script aún presenta algunos problemas de portabilidad con OpenServer 5.0.6 y Unicos 9.0.2, que solo tienen /bin/env y no /usr/bin/env .
El uso de #!/usr/bin/env da como resultado una indirección en tiempo de ejecución , lo que tiene el potencial de degradar la seguridad del sistema; por esta razón, algunos comentaristas recomiendan no usarlo [17] en software empaquetado, reservándolo solo para "ejemplos educativos".
Otro problema de portabilidad es la interpretación de los argumentos de los comandos. Algunos sistemas, incluido Linux, no dividen los argumentos; [18] por ejemplo, al ejecutar el script con la primera línea,
#!/usr/bin/env python3 -c
Todo el texto después del primer espacio se trata como un único argumento, es decir, python3 -cse pasará como un argumento a /usr/bin/env en lugar de dos. Cygwin también se comporta de esta manera.
Las invocaciones complejas de intérpretes son posibles mediante el uso de un contenedor adicional . FreeBSD 6.0 (2005) introdujo una opción -S en su env , ya que cambió el comportamiento de lectura de shebang a no división. Esta opción le dice a env que divida la cadena por sí mismo. [19] La utilidad GNU env desde coreutils 8.30 (2018) también incluye esta característica. [20] Aunque el uso de esta opción mitiga el problema de portabilidad en el extremo del núcleo con la división, agrega el requisito de que env admita esta extensión en particular.
Otro problema son los scripts que contienen un carácter de retorno de carro inmediatamente después de la línea shebang, tal vez como resultado de ser editados en un sistema que utiliza saltos de línea DOS , como Microsoft Windows . Algunos sistemas interpretan el carácter de retorno de carro como parte del comando del intérprete , lo que da como resultado un mensaje de error. [21]
El shebang es en realidad una instancia legible por humanos de un número mágico en el archivo ejecutable, siendo la cadena de bytes mágicos 0x23 0x21 , la codificación de dos caracteres en ASCII de #! . Este número mágico es detectado por la familia de funciones " exec ", que determinan si un archivo es un script o un binario ejecutable. La presencia del shebang dará como resultado la ejecución del ejecutable especificado, generalmente un intérprete para el lenguaje del script. Se ha afirmado [22] que algunas versiones antiguas de Unix esperan que el shebang normal esté seguido de un espacio y una barra ( ), pero esto parece ser falso; [11] en cambio, tradicionalmente se han permitido los espacios en blanco después del shebang, y a veces se han documentado con un espacio, como se describe en el correo electrónico histórico de 1980 a continuación.#! /
Los caracteres shebang se representan con los mismos dos bytes en las codificaciones ASCII extendidas , incluyendo UTF-8 , que se usa comúnmente para scripts y otros archivos de texto en los sistemas actuales similares a Unix. Sin embargo, los archivos UTF-8 pueden comenzar con la marca de orden de bytes (BOM) opcional; si la función "exec" detecta específicamente los bytes 0x23 y 0x21 , entonces la presencia de la BOM ( 0xEF 0xBB 0xBF ) antes del shebang evitará que se ejecute el intérprete de scripts. Algunas autoridades recomiendan no usar la marca de orden de bytes en scripts POSIX (similares a Unix), [23] por esta razón y por cuestiones filosóficas y de interoperabilidad más amplias. Además, una marca de orden de bytes no es necesaria en UTF-8, ya que esa codificación no tiene problemas de endianness ; solo sirve para identificar la codificación como UTF-8. [23]
Un archivo ejecutable que comienza con una directiva de intérprete se denomina simplemente script, a menudo precedido por el nombre o la clasificación general del intérprete previsto. El nombre shebang para los dos caracteres distintivos puede provenir de una contracción inexacta de SHArp bang o haSH bang , en referencia a los dos nombres típicos de Unix para ellos. Otra teoría sobre el sh en shebang es que proviene del shell predeterminado sh , generalmente invocado con shebang. [24] Este uso era común en diciembre de 1989, [25] y probablemente antes.
Dennis Ritchie introdujo esta característica entre las ediciones 7 y 8 en los Laboratorios Bell. También se añadió a las versiones BSD de la Investigación en Ciencias de la Computación de Berkeley (presente en 2.8BSD [26] y activada por defecto en 4.2BSD). Como la Edición 8 de Unix de los Laboratorios Bell de AT&T y las ediciones posteriores no se lanzaron al público, la primera aparición ampliamente conocida de esta característica fue en BSD.
La falta de una directiva de interpretación, pero el soporte para scripts de shell, es evidente en la documentación de la versión 7 de Unix en 1979, [27] que describe en cambio una función del shell Bourne donde los archivos con permiso de ejecución serían manejados especialmente por el shell, que (a veces dependiendo de los caracteres iniciales del script, como ":" o "#") generaría un subshell que interpretaría y ejecutaría los comandos contenidos en el archivo. En este modelo, los scripts solo se comportarían como otros comandos si se los invocara desde dentro de un shell Bourne. Un intento de ejecutar directamente un archivo de este tipo a través de la llamada al sistema exec() del propio sistema operativo fallaría, impidiendo que los scripts se comportaran de manera uniforme como comandos normales del sistema.
En versiones posteriores de sistemas similares a Unix, esta inconsistencia se eliminó. Dennis Ritchie introdujo el soporte del núcleo para directivas de intérprete en enero de 1980, para la versión 8 de Unix , con la siguiente descripción: [26]
De uucp jueves 10 de enero 01:37:58 1980>Desde dmr jue 10 ene 04:25:49 1980 remoto de investigaciónSe ha cambiado el sistema de manera que si se está ejecutando un archivocomienza con los caracteres mágicos #!, el resto de la línea se entiendeser el nombre de un intérprete para el archivo ejecutado.Anteriormente (y de hecho todavía) la concha hacía gran parte de este trabajo;Se ejecutó automáticamente en un archivo de texto con modo ejecutable.cuando el nombre del archivo de texto se escribió como comando.Al poner la instalación en el sistema se obtiene lo siguientebeneficios.1) Hace que los scripts de shell se parezcan más a archivos ejecutables reales,porque pueden ser objeto de 'ejecutivo'.2) Si haces un 'ps' mientras se ejecuta dicho comando, es realEl nombre aparece en lugar de 'sh'.De igual forma la contabilidad se realiza sobre la base del nombre real.3) Los scripts de shell pueden tener un ID de usuario establecido . [a]4) Es más sencillo tener shells alternativos disponibles;Por ejemplo, si te gusta la Berkeley CSH, no hay duda al respecto.¿Qué shell debe interpretar un archivo?5) Permitirá que otros intérpretes se integren más fácilmente.Para aprovechar esta maravillosa oportunidad,poner #! /bin/sh en el margen izquierdo de la primera línea de sus scripts de shell.Los espacios en blanco después de ! son aceptables. Utilice una ruta completa (no se realiza ninguna búsqueda).Por el momento, toda la línea está restringida a 16 caracteres, peroEste límite se aumentará.
Sin embargo, el creador de la función no le dio un nombre: [29]
De: "Ritchie, Dennis M (Dennis)** CTR **" <dmr@[redacted]> Para: <[redacted]@ talisman.org > Fecha: jue, 19 nov 2009 18:37:37 -0600 Asunto: RE: ¿Cómo llamas a tu línea #!<algo> ? No recuerdo que alguna vez le diéramos un nombre propio.Fue bastante tarde cuando entró, creo que yo...Tuve la idea de alguien en una de las conferencias de UCB.en Berkeley Unix; puede que haya sido uno de los primeros enEn realidad lo instalo, pero fue una idea que tuve.De otro lugar.En cuanto al nombre: probablemente algo descriptivo como"hash-bang" aunque tiene un sabor específicamente británico, peroEn cualquier caso, no recuerdo haber usado ningún apodo en particular.para la construcción.El soporte del kernel para directivas de intérprete se extendió a otras versiones de Unix, y una implementación moderna se puede ver en el código fuente del kernel de Linux en fs/binfmt_script.c . [30]
Este mecanismo permite que los scripts se utilicen en prácticamente cualquier contexto en el que puedan estar los programas compilados normales, incluso como programas de sistema completos e incluso como intérpretes de otros scripts. Sin embargo, como advertencia, algunas versiones tempranas del soporte del núcleo limitaban la longitud de la directiva de intérprete a aproximadamente 32 caracteres (solo 16 en su primera implementación), no lograban separar el nombre del intérprete de ningún parámetro en la directiva o tenían otras peculiaridades. Además, algunos sistemas modernos permiten que todo el mecanismo se restrinja o deshabilite por motivos de seguridad (por ejemplo, la compatibilidad con set-user-id se ha deshabilitado para scripts en muchos sistemas).
Tenga en cuenta que, incluso en sistemas con soporte completo del núcleo para el número mágico #!, algunos scripts que carecen de directivas de interpretación (aunque por lo general aún requieren permiso de ejecución) aún se pueden ejecutar en virtud del manejo de scripts heredado del shell Bourne, aún presente en muchos de sus descendientes modernos. Los scripts son luego interpretados por el shell predeterminado del usuario.
{{cite book}}: CS1 maint: varios nombres: lista de autores ( enlace )Es mucho mejor probar los scripts directamente en un shell compatible con POSIX, si es posible. La opción `bash --posix` no es suficiente, ya que aún acepta algunos 'bashismos'
Si la primera línea de un archivo de comandos de shell comienza con los caracteres "#!", los resultados no se especifican.
Macro: AC_SYS_INTERPRETER: Comprueba si el sistema admite el inicio de scripts con una línea del formato '#!/bin/sh' para seleccionar el intérprete que se utilizará para el script.