科技 · 實用指南
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 寫成 user 不是 CRLF。
若用 /usr/bin/env，確認 env 與目標程式在同一情境能解析，不要假設所有 PATH 與根檔案系統相同。
區分 ENOENT、EACCES 與繞過
No such file 可能指腳本或解譯器，也包含被 CR 汙染的名稱；存取錯誤則指向路徑搜尋、型別、執行位元或 noexec。
bash script.sh 成功只證明 Bash 能讀檔，不證明直接 shebang 正確。
套用最小修復
只有位元組證明 0d 0a 時才轉為 LF；路徑錯只改 shebang；解譯器不存在就安裝或選擇預期執行環境。
EACCES 要檢查執行位元、父目錄搜尋權限、檔案型別與掛載選項，不要一次混合多項修復。
預防復發並做退出測試
跨平台倉庫可審查 *.sh text eol=lf；在乾淨工作樹中檢查重新正規化差異。
回到原失敗情境直接執行並確認解譯器、首行位元組與簽出策略；錯誤類型若改變就分開診斷。
