Tecnología · GUÍA PRÁCTICA
¿Bash dice “bad interpreter”? Inspeccione los bytes del shebang antes de convertir
Separe CRLF, una ruta errónea, un intérprete ausente y fallos de acceso antes de editar.
bad interpreter es evidencia sobre la ejecución directa, no prueba de que Bash esté roto. Linux lee la primera línea del script ejecutable como ruta del intérprete.
No empiece con dos2unix, chmod, otro shebang ni bash script.sh. Conserve el error y los bytes, separe ENOENT de EACCES y cambie solo el límite demostrado.
Congele el error y los bytes de la primera línea
Anote el comando y mensaje exactos. Use od -An -t x1 -N 64 script.sh u otra vista de bytes: CRLF termina en 0d 0a y LF en 0a.
Registre también file, ls -l y el contexto del sistema de archivos o contenedor. Editar o volver a descargar puede borrar la evidencia.
Resuelva la ruta literal del intérprete
Lea exactamente lo que sigue a #!, confirme ruta absoluta, ortografía y existencia en el mismo entorno. Falta de barra o confundir usr con user no es CRLF.
Con /usr/bin/env, verifique env y el programa en el mismo contexto; no suponga igual PATH o raíz en shell, CI y contenedor.
Separe ENOENT, EACCES y el desvío
No such file puede referirse al script o intérprete, incluido un nombre con CR. El error de acceso apunta a búsqueda, tipo, bit de ejecución o noexec.
Que bash script.sh funcione solo prueba que Bash puede leerlo; no valida el shebang directo.
Aplique la reparación mínima demostrada
Convierta a LF solo si los bytes muestran 0d 0a y vuelva a inspeccionar. Corrija solo el shebang o instale el runtime previsto según la evidencia.
Para EACCES revise bits, directorios padre, tipo de archivo y montaje. No mezcle varias reparaciones.
Evite la recurrencia y pruebe directamente
En Git multiplataforma considere *.sh text eol=lf y revise la renormalización en un árbol limpio.
Ejecute directamente en el contexto original y confirme intérprete, bytes y política de checkout. Si cambia la clase de error, diagnóstiquela por separado.
