¿Cuál es la diferencia entre ./ y sh para ejecutar un script?

He escrito un guión simple. Cuando corro sh <myscriptname.sh>, obtuve el resultado correcto, pero cuando corro ./<myscriptname.sh>, recibí un error.

¿Cuál es la diferencia entre cuando lo hago shy ./?

Cuando ejecuta un script pasando el nombre del archivo al programa de intérprete de script, está ejecutando el programa de intérprete con el script como un argumento que se le pasa. Por ejemplo, esto se vería como el proceso 'sh' con el argumento 'filename.sh'. El shintérprete está abriendo el archivo.

Por otro lado, si ejecuta el script en sí, el sistema llama al programa de intérprete especificado y alimenta el contenido del script. En este caso, el proceso se parece a 'filename.sh' sin argumentos.

Debes asegurarte de tener una línea de explosión:

#!/bin/bash
# bash script here

Una línea de explosión es la primera línea del script y comienza con los mismos dos caracteres #!, estos son los que el sistema lee cuando intenta ejecutar el script y luego el sistema pasa el script al programa inmediatamente después. Tenga en cuenta que esta línea no tiene nada que ver con bash y funciona igual de bien para python y perl, a pesar de que son idiomas muy diferentes. Usaría, #!/usr/bin/pythonpor ejemplo, y luego lo seguiría con el código de Python.

Una vez que tenga su script, asegúrese de haber configurado los permisos de ejecución:

chmod a+x filename.sh

Luego puede ejecutar el script como su propio proceso:

./filename.sh

O coloque el archivo en una ubicación conocida con un buen nombre de programa, como /usr/sbiny ejecute desde cualquier lugar:

sudo cp filename.sh /usr/sbin/program-name
program-name

Y este es realmente el beneficio práctico de usar la línea de explosión con los permisos correctos: se trata de la implementación . Es muy difícil lograr que los usuarios ejecuten un script si tienen que recordar con qué programa ejecutar el script. Recuerde dar una ruta completa al script cada vez que quieran ejecutarlo. Donde ponerlo, /usr/local/binpor ejemplo, y hacerlo ejecutable, puede ahorrar una gran pena para las personas que intentan usar su script. Estos programas estarán disponibles para todos los usuarios en su computadora.

También es bueno para la identificación. Si ingresa al topprograma, una secuencia de comandos ejecutada sin la línea de explosión solo tendrá el nombre del intérprete bash, es decir , perlo python. Pero si se ejecuta un script con los permisos correctos, entonces se muestra el nombre del script.

Nota: Si desea distribuir una secuencia de comandos que sea accesible para todos, cree una página de manual y un paquete deb para instalarlo. Necesitamos reducir la cantidad de scripts aleatorios en línea y aumentar la cantidad de debs que se pueden desinstalar.

La versión corta:

• shes el intérprete de línea de comandos (guión).
  La ejecución sh my_scripthace que dash interprete el script.

• ./intenta averiguar qué intérprete usar, mirando la primera línea. Por ejemplo #!/bin/bash, o incluso #!/bin/ruby(en lugar de correr ruby my_script).

La diferencia que haces es

• con sh, está ejecutando un programa que interpretará las líneas en su secuencia de comandos tal como las habría escrito en el mensaje interactivo del terminal,

• con el ./que está haciendo un acceso directo suponiendo que la secuencia de comandos está justo aquí en el directorio actual en el que está sentado Y será ejecutable (porque, por ejemplo, emitió chmod +x myscript.sh), ahorrándole un tiempo invaluable para tiempos futuros :-)

Hay tres razones principales por las que puede recibir un error:

• el archivo no es ejecutable
  ejecute chmod +x <myscriptname.sh>para arreglar eso
• la partición no permite ejecutar scripts (está " noexec" montado ),
  copie el script en/usr/local/bin
• la #!línea tiene un error,
  asegúrese de que la primera línea es #!/bin/sho#!/bin/bash

Si su primera línea se ve bien, pero aún no funciona, asegúrese de que el archivo no tenga terminaciones de línea DOS.

El error se vería así:

$ ./myscript.sh
bash: ./myscript.sh: /bin/bash^M: bad interpreter: No such file or directory

Puede solucionarlo ejecutando dos2unix <myscriptname.sh>, o si no tiene eso
perl -p -i -e 's/\r\n$/\n/' <myscriptname.sh>,.

Y la respuesta es que sh es el nombre de un shell muy popular. Pero anticuado y reemplazado por otros. Hoy en día sh está vinculado a otras carcasas instaladas en la máquina. Por ejemplo, he golpeado allí. Ejecutar cualquier shell desde sh generalmente desencadena un modo de "compatibilidad" con el comportamiento original de "shell".

Entonces la solución es bastante simple. Mire lo que hay detrás del comando sh (ls -al / bin / sh) y coloque #! / Bin / whatever_you_find_there como primera línea (o si hay algo así en su script, edítelo).

Y, alternativamente, puede haber algún error en el script en sí. Como la dependencia que cumple sh, pero no el intérprete que realmente se usa.

mkdir ~/bin ; cp myscript.sh ~/bin/

echo "export PATH="$PATH:/home/$USER/bin" >> ~/.profile ; source ~/.profile ; 

No /usr/sbin, eso es para herramientas administrativas no esenciales, /usr/local/bines una mejor opción si no desea tener una ~/bin/, pero sudoes aconsejable evitar tanto como sea posible.