Para iniciar el script de shell 'file.sh':
sh file.sh
bash file.sh
Otra opción es configurar el permiso ejecutable usando el comando chmod:
chmod +x file.sh
Ahora ejecute el archivo .sh de la siguiente manera:
./file.sh
Para ejecutar un sh no ejecutable secuencia de comandos, utilice:
sh myscript
Para ejecutar un bash no ejecutable secuencia de comandos, utilice:
bash myscript
Para iniciar un ejecutable (que es cualquier archivo con permiso de ejecución); 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 descubrir cómo ejecutarlo. Para los no binarios, esto se hace mirando la primera línea del archivo. Debe contener un 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 se pasa al programa (como segundo argumento) junto con todos los argumentos que le dio a la secuencia de comandos como argumentos posteriores.
Eso significa que cada secuencia de comandos ejecutable debe tener un hashbang . Si no es así, no le está diciendo al núcleo lo que es , y por lo tanto el núcleo no sabe qué programa usar para interpretarlo. Podría ser bash , perl , python , sh , o algo mas. (En realidad, el kernel a menudo usará el shell predeterminado del usuario para interpretar el archivo, lo cual es muy peligroso porque podría no ser el intérprete correcto en absoluto o podría analizar parte de él, pero con sutiles diferencias de comportamiento como es el caso entre sh y bash ).
Una nota sobre /usr/bin/env
Lo más común es que veas hash bangs así:
#!/bin/bash
El resultado es que el kernel ejecutará el programa /bin/bash para interpretar el guión. Desafortunadamente, bash no siempre se envía de forma predeterminada y no siempre está disponible en /bin . Mientras que en las máquinas Linux suele ser así, hay una gama de otras máquinas POSIX donde bash se envía a varias ubicaciones, como /usr/xpg/bin/bash o /usr/local/bin/bash .
Por lo tanto, para escribir un script bash portátil, no podemos confiar en codificar la ubicación del bash programa. 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 su programa cuando desee ejecutarlo por su nombre.
Lamentablemente, no puedes solo haz esto:
#!bash
El núcleo no hará (algunos podrían) hacer un PATH buscarte Hay un programa que puede hacer un PATH buscarte, sin embargo, se llama env . Afortunadamente, casi todos los sistemas tienen un env programa instalado en /usr/bin . Entonces comenzamos env usando una ruta codificada, que luego hace un PATH busca bash y lo 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 argumento del env programa. Eso significa que no tenemos espacio para pasar argumentos a bash . Entonces no hay forma 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 pueden enviarse con un /bin/bash , pero es posible que al usuario no le guste, que tenga errores o que esté desactualizado y que haya instalado su propio bash en algún otro lugar. Este suele ser 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 usas el env enfoque que hace un PATH búsqueda, se tiene en cuenta la preferencia del usuario y se utiliza su bash preferido sobre el que viene con su sistema.
Para la concha bourne:
sh myscript.sh
Para bash:
bash myscript.sh