Los scripts de Bash no se ejecutarán sin escribir "bash" delante de él

En nuestro sistema escolar, estamos en condiciones de ejecutar archivos de comandos sin necesidad de escribir basho csho lo que sea, sin indicar qué tipo guión es. Sin embargo, en Ubuntu, debo escribir, bash script.bashpor ejemplo. ¿Esto siempre es necesario en Ubuntu, o es una configuración que puedo cambiar?

bash

— muttley91
fuente

¿Está configurado como un archivo ejecutable?

— jsolarski

Sí, el archivo es ejecutable, por lo que creo que se ejecutará solo.

— muttley91

¿Qué error obtienes cuando escribes ./script? ¿Está seguro de que la secuencia de comandos no se cambió desde un editor de Windows que coloca un carácter adicional al final de las líneas? Eso rompería la primera línea que señala que el script debe ejecutarse con bash.

— João Pinto

¿Cómo se inicia y cuál es el mensaje de error?

— usuario desconocido

+1 por no usar .shpara secuencias de comandos bash. Sin embargo, generalmente las extensiones de archivo no se usan para scripts ejecutables en el mundo UNIX.

— nyuszika7h

Respuestas:

Asegúrese de iniciar el script con ./scriptla ruta completa o lo que sea. Es scriptposible que no funcione (funciona si el directorio está en $PATH, como /usr/bin), ya que en los sistemas UNIX no es costumbre tener el directorio actual en su camino (por razones de seguridad, ¡y es bueno!)
Asegúrese de que el script sea ejecutable, por ejemplo: chmod +x scriptlo hará ejecutable.
Asegúrese de tener #!/bin/bashcomo primera línea en su secuencia de comandos. También asegúrese de que no esté editado con algún tipo de editor de Windows, ya que a menudo usa el "tipo DOS" de eol (final de línea) que difiere del UNIX (si la lista de verificación anterior está bien, pero tiene "mal" intérprete: no existe tal archivo o directorio ", más o menos, incluso si es / bin / bash, esta suele ser la razón, ya que no es imprimible, por lo que generalmente no lo ve, \ r será tratado como parte de la camino del intérprete)

Otros ya lo mencionaron: es importante tenerlo /bin/bashsi usas las funciones de bash, también /bin/shestaba enlazado a un enlace simbólico /bin/bash, pero ahora (hasta donde he notado) está enlazado a un enlace simbólico dashque no proporcionará compatibilidad con bash, solo POSIX sh. Es bastante importante, incluso los softwares bastante caros en nuestra empresa tienen este problema: los scripts contienen #!/bin/shcomo primera línea pero también dependen de las funcionalidades de bash.

— LGB
fuente

Así que tendré que ejecutarlo así: ./script, como he descubierto. Esto es mejor que tener que escribir "bash" cada vez, y tiene sentido. Creo que sabía esto antes, simplemente se me pasó por la cabeza. Oh bueno, gracias!

— muttley91

En teoría, puede colocar el directorio de trabajo actual en la variable PATH para que pueda usar solo "script" en lugar de "./script", pero le advierto: esto realmente no es un hábito en los sistemas UNIX y puede ser un problema de seguridad ! También no es agradable en una escuela para aprender cosas de una manera que nunca ha sido la solución en sistemas UNIX, por lo que evitaría esta solución ...

— LGB

O, preferiblemente, #!/usr/bin/env bashque es un poco más portátil.

— Sparhawk

Asegúrese de que la primera línea del archivo lea:

#!/bin/bash

Si el shebang es #!/bin/sh, no debe usar ninguna característica específica de bash, solo características POSIX. Incluso si se /bin/shtrata de un enlace simbólico bash, bash se ejecutará en un modo de compatibilidad POSIX cuando se ejecute como sh, deshabilitando algunas (pero no todas) las funciones de bash.

También deberá asegurarse de que el script sea ejecutable, por supuesto.

— geirha
fuente

No, lo configuré para golpear por costumbre de todos modos.

— muttley91

Una forma alternativa, fuertemente desaconsejada es agregar .a PATH.

PATH=".:$PATH"

PATH="$PATH:."

El problema con este enfoque es que, en el primer caso, cualquier comando del sistema podría anularse con ejecutables del directorio actual, y en el último caso, los comandos desconocidos aún podrían anularse.

Considera lo siguiente:

Archivo: ls

#!/bin/bash

./my_malicious_script &>/dev/null
/bin/ls "$@"

Lo más probable es que ni siquiera lo note hasta que sea demasiado tarde.

— nyuszika7h
fuente

La elección de palabras es un poco engañosa aquí. Los comandos no serán anulados. Si tiene un comando en el directorio de trabajo actual que tiene el mismo nombre que el que vive en los directorios del sistema, digamos, echopor ejemplo, el que está en su directorio se usará simplemente porque ese directorio está configurado en una PATHvariable antes del /bin. Shell simplemente busca comandos en directorios particulares dependiendo de su orden PATHy no anula / destruye nada. Pero sí, esto tiene implicaciones

— Sergiy Kolodyazhnyy