기술 · 실용 가이드
Bash “bad interpreter”? 변환 전에 shebang 바이트부터 확인하세요
CRLF, 잘못된 경로, 누락된 런타임, 접근 거부를 구분한 뒤 수정합니다.
bad interpreter는 직접 실행 경계의 증거이지 Bash 자체가 고장 났다는 뜻은 아닙니다. Linux는 실행 스크립트 첫 줄을 인터프리터 경로로 읽습니다.
처음부터 dos2unix, chmod, shebang 변경이나 bash script.sh 우회를 하지 말고 오류와 첫 줄 바이트를 보존해 ENOENT와 EACCES를 나누세요.
오류와 첫 줄 바이트를 고정하세요
원래 명령과 메시지를 기록하고 od -An -t x1 -N 64 script.sh 등으로 첫 줄을 봅니다. CRLF는 0d 0a, LF는 0a입니다.
file, ls -l, 파일시스템·컨테이너 문맥도 남기세요. 편집이나 재체크아웃은 증거를 지웁니다.
커널이 보는 경로를 해석하세요
#! 뒤를 바이트 그대로 읽고 절대 경로, 철자와 같은 실행 환경에서의 존재를 확인합니다. 슬래시 누락이나 usr 오타는 CRLF가 아닙니다.
/usr/bin/env라면 env와 대상 프로그램이 같은 문맥에서 해석되는지 확인합니다.
ENOENT, EACCES와 우회를 구분하세요
No such file은 스크립트나 인터프리터를 가리키며 CR이 섞인 이름도 포함합니다. 접근 오류는 검색 권한, 형식, 실행 비트나 noexec를 뜻합니다.
bash script.sh 성공은 Bash가 파일을 읽는다는 증거일 뿐 직접 shebang이 맞다는 증거가 아닙니다.
증명된 최소 수정만 적용하세요
0d 0a를 확인했을 때만 LF로 변환하고 다시 봅니다. 경로만 틀리면 shebang만, 런타임이 없으면 의도한 런타임을 고칩니다.
EACCES는 실행 비트, 상위 디렉터리, 파일 형식과 마운트를 감사하며 여러 변경을 섞지 않습니다.
재발을 막고 직접 종료 시험을 하세요
교차 플랫폼 Git에는 *.sh text eol=lf를 검토하고 깨끗한 작업 트리에서 정규화 차이를 확인합니다.
원래 문맥에서 직접 실행해 인터프리터, 바이트, 체크아웃 정책을 확인합니다. 오류 종류가 바뀌면 별도로 진단합니다.
