¿Cómo ejecutar un script de Shell en una consola Unix o terminal de Mac?

Para ejecutar un script sh no ejecutable, use:

sh myscript

Para ejecutar un script bash no ejecutable, use:

bash myscript

Para iniciar un ejecutable (que es cualquier archivo con permiso ejecutable); simplemente lo especificas por su ruta:

/foo/bar
/bin/bar
./bar

Para hacer un script ejecutable, dale el permiso necesario:

chmod +x bar
./bar

Cuando un archivo es ejecutable, el kernel es responsable de averiguar cómo ejecutarlo. Para los no binarios, esto se hace mirando la primera línea del archivo. Debe contener una hashbang:

#! /usr/bin/env bash

El hashbang le dice al núcleo qué programa ejecutar (en este caso, el comando /usr/bin/env se ejecuta con el argumento bash). Luego, la secuencia de comandos pasa al programa (como segundo argumento) junto con todos los argumentos que dio a la secuencia de comandos como argumentos posteriores.

Eso significa que cada script que sea ejecutable debe tener un hashbang . Si no lo hace, no le está diciendo al kernel qué es es , y por lo tanto el kernel no sabe qué programa usar para interpretarlo. Podría ser bash, Perl, python, sh, o algo más. (En realidad, el kernel a menudo usará el Shell predeterminado del usuario para interpretar el archivo, lo cual es muy peligroso porque puede que no sea el intérprete correcto o podría analizarlo, pero con diferencias de comportamiento sutiles, como el caso entre sh y bash).

Una nota en /usr/bin/env

Lo más común es que veas explosiones de hash así:

#!/bin/bash

El resultado es que el kernel ejecutará el programa /bin/bash para interpretar el script. Desafortunadamente, bash no siempre se envía de forma predeterminada, y no siempre está disponible en /bin. Mientras que en las máquinas con Linux suele ser así, hay una variedad de otras máquinas POSIX donde bash se envía en varias ubicaciones, como /usr/xpg/bin/bash o /usr/local/bin/bash.

Para escribir un script de bash portátil, por lo tanto, no podemos confiar en la codificación del lugar del programa bash. POSIX ya tiene un mecanismo para lidiar con eso: PATH. La idea es que instales tus programas en uno de los directorios que están en PATH y el sistema debería poder encontrar tu programa cuando quieras ejecutarlo por su nombre.

Lamentablemente, usted no puede simplemente haga esto:

#!bash

El kernel no (algunos podrían) hacer una búsqueda PATH para usted. Hay un programa que puede hacer una búsqueda de PATH para ti, sin embargo, se llama env. Afortunadamente, casi todos los sistemas tienen un programa env instalado en /usr/bin. Así que comenzamos env usando una ruta codificada, que luego realiza una búsqueda PATH para bash y la ejecuta para que pueda interpretar su script:

#!/usr/bin/env bash

Este enfoque tiene un inconveniente: según POSIX, el hashbang puede tener un argumento . En este caso, usamos bash como el argumento del programa env. Eso significa que no tenemos espacio para pasar argumentos a bash. Así que no hay manera de convertir algo como #!/bin/bash -exu a este esquema. Tendrás que poner set -exu después del hashbang en su lugar.

Este enfoque también tiene otra ventaja: algunos sistemas se pueden enviar con un /bin/bash, pero al usuario no le gusta, puede encontrar que está defectuoso o desactualizado, y puede haber instalado su propia bash en otro lugar. Este es a menudo el caso en OS X (Mac) donde Apple envía un /bin/bash obsoleto y los usuarios instalan un /usr/local/bin/bash actualizado usando algo como Homebrew. Cuando utiliza el enfoque env que realiza una búsqueda PATH, tiene en cuenta las preferencias del usuario y utiliza su evento preferido sobre el sistema con el que se envió su sistema.