19 votos

¿Por qué tengo que poner sh antes de ejecutar los archivos .sh?

Cuando quiero correr .sh en el Terminal, tengo que poner sh frente a ellos.

¿Hay alguna forma de evitar esto y así ahorrar en la escritura?

3 votos

Hice una carpeta en ~/bin para poner mi shell scripts y lo puse en mi $PATH y también adjunté una Acción de Carpeta a la carpeta ~/bin para establecer automáticamente los permisos de ejecución porque es muy fácil olvidarse de hacerlo.

24voto

Wolfram Kriesing Puntos 1141

Si estás ejecutando tu script desde el shell, no necesitas el #!/bin/sh el tinglado como se indica en este esta respuesta -todos los sistemas de tipo Unix que he utilizado, incluido OS X, se ajustan por defecto a /bin/sh si no se especifica específicamente ningún intérprete (aunque es una buena idea, ya que los que no son shell no sabrán cómo ejecutar tu script a menos que le des el shebang).

Tampoco es necesario un .sh extensión. Usted hacer necesita establecer los permisos de los ejecutables, por ejemplo

$ chmod +x script.sh

(El $ es el prompt del shell; lo estoy usando para ilustrar los comandos que se dan al shell interactivo. No lo escribas).

Sin embargo, creo que lo que te confunde es que has creado un script, por ejemplo. script.sh en el directorio actual, e intentan ejecutarlo simplemente escribiendo script.sh . por ejemplo

$ cat >script.sh
echo hello, world
^D
$ chmod +x script.sh
$ script.sh
-bash: script.sh: command not found

( ^D significa control - D . Encontrará esta notación en muchos escritos sobre el uso de Unix).

El hecho de que script.sh en este caso es un shell script es sólo la mitad del problema; su problema real es que, por defecto, el shell no buscará un programa en el directorio actual. Sin embargo, esto funciona:

$ sh script.sh
hello, world

porque sh toma el script como argumento.

Puede ejecutar un script-o, de nuevo, cualquier ejecutable-en el directorio actual, si está marcado como ejecutable (es decir chmod +x ), especificando que desea ejecutar el del directorio actual:

$ ./script.sh
hello, world

También puede mover el script a un directorio de su PATH . Recomiendo /usr/local/bin para esto si su script está destinado a ser utilizado en todo el sistema, o un bin en su casa si el script es sólo para usted. Esto último requiere que añadas $HOME/bin que se expande a su nuevo directorio bin, a su PATH añadiendo las siguientes líneas a su .profile en su directorio principal:

PATH=$HOME/bin:$PATH
export PATH

Por último, si lo desea, puede añadir el directorio actual a su PATH que le permitirá simplemente ir a un directorio que contenga script.sh -o cualquier otro ejecutable- y escriba

$ script.sh

para ejecutarlo. Sin embargo, No recomiendo esta práctica ya que un atacante puede ahora engañarle para que ejecute un ejecutable arbitrario dejando caer un script ejecutable (llamado, digamos, ls ) en un directorio en el que estará. Si usted realmente quiere hacerlo, sólo tiene que añadir lo siguiente a su .profile :

PATH=.:$PATH
export PATH

0 votos

Pon el '.' al final del $PATH en vez de al principio y ahora no tendrás que preocuparte por un 'ls' fantasma. (Aunque si alguien puede entrar en tu sistema, tienes problemas mayores).

2 votos

@TJ, pero tú hacer necesita preocuparse por cosas como sl o lls o l ... es decir, los errores tipográficos. Sólo hay que dejar . de $PATH . Además, es posible que no confíes (o no debas) necesariamente en todas las personas de tu sistema. Por ejemplo, supongamos que hay algún exploit que permite a un atacante soltar un archivo arbitrario en algún directorio, pero necesitan usted para ejecutar ese archivo con el fin de escalar a un exploit mejor (por ejemplo, recoger datos y llamar a casa). ¡Defensa en profundidad!

0 votos

@TJLuoma Lo que dijo @Reid, además de tener en cuenta que hay muchos casos de uso para un sistema Unix más allá de un escritorio personal de OS X. No lo he probado, pero apuesto a que incluso la cuenta de invitado podría dejar uno de esos elementos en /tmp o algún otro directorio escribible en el mundo.

10voto

Mark Harrison Puntos 77152

No es necesario llamar sh si el archivo script está marcado como ejecutable. En ese caso, puedes llamarlo mi nombre como lo harías con cualquier otro comando del shell existente.


Para ser totalmente correcto, querrás hacer dos cosas:

  1. Edita tu script para incluir un shebang en la parte superior de su script:

    #!/bin/sh

    ... Eso le diría al shell qué intérprete usar para ejecutar el script; en este caso, el /bin/sh ejecutable.

  2. Marcar el script como ejecutable por usted con el chmod comando:

    chmod u+x scriptname.sh

Una vez que hagas ambas cosas, deberías poder ejecutar tu scriptescribiendo el nombre del archivo de tu script en la línea de comandos. Necesitarás estar en el mismo directorio que tu script, a menos que también des el paso adicional de añadir la carpeta que lo contiene a tu Variable PATH . Si no te importa qué shell ejecuta el script, no necesitas el paso uno para especificar sh pero a menudo es mejor ser preciso y fijar el "shebangsh".

0 votos

Los colgajos no son realmente necesarios para /bin/sh Aunque no hacen daño.

0 votos

@zigg - Tienes razón. Espero que a Chris no le molesten mis ediciones Nuke o reeditar como se desee :-0

0 votos

@bmike Las ediciones me funcionan. En cuanto a los shebangs, mi costumbre era especificar siempre porque solía escribir mucho ksh scripts en mis días en HP-UX - pero es bueno saber que no es estrictamente necesario.

AppleAyuda.com

AppleAyuda es una comunidad de usuarios de los productos de Apple en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros usuarios, hacer tus propias preguntas o resolver las de los demás.

Powered by:

X