Este tipo de mensaje generalmente se debe a una línea falsa de shebang, ya sea un retorno de carro adicional al final de la primera st línea o una lista de materiales al principio.

Ejecute:

$ head -1 yourscript | od -c 

y vea cómo termina.

Esto es incorrecto:

0000000 # ! / b i n / b a s h \r \n 

Esto también es incorrecto:

0000000 357 273 277 # ! / b i n / b a s h \n 

Esto es correcto:

0000000 # ! / b i n / b a s h \n 

Utilice dos2unix (o sed, tr, awk, perl, python…) para corregir su secuencia de comandos si este es el problema.

Aquí hay uno que eliminará tanto la lista de materiales como los CR finales:

sed -i "1s/^.*#//;s/\r$//" brokenScript 

Tenga en cuenta que el shell que está utilizando para ejecutar el script afectará ligeramente los mensajes de error que se muestran.

Aquí hay tres scripts que solo muestran su nombre (echo $0) y tener las siguientes líneas de shebang respectivas:

correctScript:

0000000 # ! / b i n / b a s h \n 

scriptWithBom:

0000000 357 273 277 # ! / b i n / b a s h \n 

scriptWithCRLF:

0000000 # ! / b i n / b a s h \r \n 

En bash, ejecutarlos mostrará estos mensajes:

$ ./correctScript ./correctScript $ ./scriptWithCRLF bash: ./scriptWithCRLF: /bin/bash^M: bad interpreter: No such file or directory $ ./scriptWithBom ./scriptWithBom: line 1: #!/bin/bash: No such file or directory ./scriptWithBom 

Ejecutando el bo gus one al llamar explícitamente al intérprete permite que el script CRLF se ejecute sin ningún problema:

$ bash ./scriptWithCRLF ./scriptWithCRLF $ bash ./scriptWithBom ./scriptWithBom: line 1: #!/bin/bash: No such file or directory ./scriptWithBom 

Aquí está el comportamiento observado en ksh:

$ ./scriptWithCRLF ksh: ./scriptWithCRLF: not found [No such file or directory] $ ./scriptWithBom ./scriptWithBom[1]: #!/bin/bash: not found [No such file or directory] ./scriptWithBom 

y debajo de dash:

$ ./scriptWithCRLF dash: 2: ./scriptWithCRLF: not found $ ./scriptWithBom ./scriptWithBom: 1: ./scriptWithBom: #!/bin/bash: not found ./scriptWithBom 

Comentarios

• Otra forma de revelar si este es el problema es hexdump -C yourscript | head -n 1. Todavía usaría dos2unix yourscript para solucionarlo.
• Si fuera un problema de CRLF, no ‘ ver un #!/bin/bash no such file or directory mensaje de error, ya que ‘ no hay razón para que algo intente ejecutar o abrir #!/bin/bash. Es ‘ s /bin/bash<CR> lo que se ejecutaría.
• @StephaneChazelas Como dos2unix solucionó el problema, hay pocas dudas no era ‘ un problema de CRLF. El mensaje de error probablemente se transcribió de forma incorrecta.
• dos2unix también elimina una lista de materiales UTF-8. Una BOM UTF-8 podría haber explicado el mensaje de error.
• Es triste lo incompatible que es Microsoft. Incluso con algo tan básico como ASCII.

Esto también puede ser causado por una lista de materiales en un UTF -8 guión. Si crea la secuencia de comandos en Windows, a veces obtiene algo de basura al comienzo del archivo.

Comentarios

• BOM se puede eliminar fácilmente usando awk, como en stackoverflow.com/questions/1068650/…
• Tenga en cuenta que Visual Studio para Mac insertará una lista de materiales.

En realidad, el tema correcto para el script bash es este:

#!/usr/bin/env bash 

Porque, en freeBSD, bash se encuentra en /usr/local/bin/bash

Comentarios

• » right » es una palabra difícil de usar en tales casos. Quizás una mejor frase sería » menos propensa a errores «.
• Esto también es terrible; la suposición de que existe / usr es mala en mi opinión. Haiku, por ejemplo, no tiene / usr.

Puede usar vi para solucionar ambos problemas si existen:

vi <your_file> :set ff=unix :set nobomb :wq 

Comentarios

• Las respuestas deben ser independientes tanto como sea posible. La pregunta no menciona dos problemas; si va a basarse en otras respuestas, debe al menos decir cuáles son. Mejor aún, debería explicar cómo esto responde a la pregunta.
• Solución muy rápida sin descargar más herramientas de Windows, ¡gracias!
• @ G-Man Otras respuestas Ya menciono esto con mucho más detalle de lo que deseo entrar.No es necesario repetir, pero si ‘ no es dolorosamente obvio, puede tener un final de línea de Windows y un carácter BOM de Windows oculto. Creo que muchas personas que escanean respuestas aprecian la brevedad en lugar de ser autosuficientes, especialmente cuando hay muchos más detalles en otras respuestas.

Si no tiene dos2unix, esta es una forma de solucionar este problema.

cp script _p4 && tr -d "\r" < _p4 > script && rm _p4 

Marca de orden de bytes (BOM)

Esto podría deberse a una BOM. De Wikipedia, una BOM es una

La marca de orden de bytes (BOM) es un carácter Unicode, U + FEFF marca de orden de bytes (BOM) , cuya aparición como un número mágico al comienzo de un flujo de texto puede indicar varias cosas a un programa que consume el texto

Desafortunadamente, no indica nada al kernel de Linux que maneja la línea she-bang. Puede verificar que tiene una lista de materiales usando file ,

file /tmp/foo /tmp/foo: UTF-8 Unicode (with BOM) text 

O puede hexdump los primeros caracteres y ver si coinciden con alguno de los caracteres BOM manualmente

Puede quitar los caracteres BOM una vez que los conozca así ,

sed -i "1 s/^\xef\xbb\xbf//" *.txt 

Tuve el problema al agregar accidentalmente un bash incorrecto ejecutable al PATH y porque en mi script se usó el #!/usr/bin/env bash shebang más flexible (tome el primer ejecutable bash de la ruta).

command -v bash /cygdrive/c/Program Files/Git/bin//bash 

He instalado GIT para Windows para que funcione en cygwin junto con las GUI de Windows GIT (no funcionaba con cygwin native git …). Resolví esto ahora cambiando a #!/bin/bash sheband y eliminando GIT para Windows de PATH.

Pruebe #!/bin/bash

Segunda cosa: find / -name bash
Tercera cosa: ls -al /bin/bash

Comentarios

• O simplemente which bash. Sabemos que ‘ s encuentra uno porque ‘ funciona con bash script.sh.
• Verdadero. Y como se mencionó, existe el método / usr / bin / env mucho más portátil para que un programa localice bash (u otro intérprete) por usted. No es necesario codificar una pah.