連載數(shù)據(jù)庫巡檢腳本的時(shí)候最讓人頭疼的不是 SQL 寫得有問題而是 Shell 腳本本身莫名其妙地給你來一個(gè) “No such file or directory”然后整個(gè)任務(wù)就在那干瞪眼。這個(gè)報(bào)錯(cuò)長(zhǎng)得特別像文件路徑不存在但你去查文件、查目錄全都好好的。最近幫同事排查一個(gè)批量連庫查詢的腳本正好把這個(gè)問題和另一個(gè)高頻坑——函數(shù)傳參數(shù)組——一起撞上了。這篇文章就把這兩個(gè)問題從現(xiàn)象、原理到解決方案完整拆一遍都是踩過坑之后的實(shí)操記錄。先交代一下背景。腳本本身不復(fù)雜就是從一臺(tái)跳板機(jī)循環(huán)連多個(gè)業(yè)務(wù)庫執(zhí)行幾條查詢語句然后把結(jié)果匯總。部署到新服務(wù)器上之后一執(zhí)行就報(bào)No such file or directory沒有任何多余信息。新手遇到這個(gè)報(bào)錯(cuò)第一反應(yīng)是去檢查 SQL 文件、日志目錄、數(shù)據(jù)文件是不是不存在但我可以負(fù)責(zé)任地說在這個(gè)場(chǎng)景里九成以上是腳本文件或執(zhí)行環(huán)境本身出了問題而不是數(shù)據(jù)庫目錄里的文件缺失。下面我按實(shí)際排查順序把“文件不存在”這個(gè)誤報(bào)的幾種根源先拆清楚再單獨(dú)說函數(shù)傳參數(shù)組的問題最后給出一套可以直接抄的完整方案。1. 報(bào)錯(cuò)現(xiàn)場(chǎng)還原先看清“No such file or directory”到底卡在哪里1.1 最容易翻車的第一現(xiàn)場(chǎng)腳本自身的行尾符我第一次在這類報(bào)錯(cuò)上栽跟頭是在 Windows 上寫完腳本、通過 Git 傳到 Linux 服務(wù)器后執(zhí)行的。寫的時(shí)候用的是記事本風(fēng)格的編輯器行尾符默認(rèn)是 CRLF\r\n而 Linux 只認(rèn) LF\n。執(zhí)行./check_db.sh的時(shí)候內(nèi)核讀取腳本第一行#!/bin/bash卻發(fā)現(xiàn)實(shí)際解析出來的是#!/bin/bash\r。它去系統(tǒng)中找/bin/bash\r這個(gè)“解釋器文件”當(dāng)然找不到于是報(bào)錯(cuò)-bash: ./check_db.sh: /bin/bash^M: bad interpreter: No such file or directory注意這里報(bào)錯(cuò)信息里的^M那就是\r回車符的可視化表示。你盯著腳本內(nèi)容看覺得完全正?？蓛?nèi)核眼里解釋器路徑就是帶著一個(gè)看不見的尾巴。這個(gè)問題在連接數(shù)據(jù)庫腳本里尤其陰險(xiǎn)因?yàn)槟_本本身可能已經(jīng)被 dos2unix 處理過但后來編輯的過程中又引入了新的 CRLF導(dǎo)致反復(fù)發(fā)作。判斷最直接的方法是file命令file check_db.sh如果輸出里包含with CRLF line terminators那就實(shí)錘了。修復(fù)也很簡(jiǎn)單dos2unix check_db.sh # 或者用 sed不依賴額外工具 sed -i s/\r$// check_db.sh處理完再執(zhí)行一次file確認(rèn)輸出變成Bourne-Again shell script, ASCII text executable就沒有行尾符問題了。1.2 第二現(xiàn)場(chǎng)解釋器路徑與執(zhí)行方式的隱性坑排除掉 CRLF 之后下一個(gè)要看的點(diǎn)是腳本的解釋器聲明和執(zhí)行方式。很多人習(xí)慣寫#!/usr/bin/env bash這本身沒問題但它在某些受限環(huán)境里會(huì)失效。env需要從 PATH 環(huán)境變量里去定位 bash如果 PATH 里沒有 bash 所在目錄同樣會(huì)報(bào)No such file or directory而且報(bào)錯(cuò)信息里可能不帶^M讓定位更難。我自己在 crontab 里跑腳本時(shí)遇到過好幾次這種問題。cron 環(huán)境的最小 PATH 通常只有/usr/bin:/bin如果 bash 裝在其他位置腳本就無法啟動(dòng)。解決辦法是腳本開頭直接寫死解釋器絕對(duì)路徑比如#!/bin/bash而不是#!/usr/bin/env bash。雖然犧牲了一點(diǎn)可移植性但換來了確定性和穩(wěn)定。另外還有一個(gè)容易被忽略的腳本文件編碼如果帶了 BOMByte Order Mark第一行的#!前面會(huì)多出三個(gè)不可見字節(jié)同樣會(huì)讓內(nèi)核找不到解釋器?？梢杂胹ed -i 1s/^\xEF\xBB\xBF// check_db.sh把 BOM 去掉。提示排查執(zhí)行類報(bào)錯(cuò)強(qiáng)烈建議先用bash -x ./check_db.sh強(qiáng)制跑一遍。這樣能跳過執(zhí)行權(quán)限和 shebang 解析的干擾直接暴露腳本內(nèi)部邏輯錯(cuò)誤是區(qū)分“腳本本身問題”和“環(huán)境問題”最快的手段。1.3 第三現(xiàn)場(chǎng)腳本內(nèi)部調(diào)用的命令或文件缺失當(dāng)腳本能正常啟動(dòng)、卻仍然報(bào)No such file or directory時(shí)問題就轉(zhuǎn)移到腳本內(nèi)部了。在數(shù)據(jù)庫查詢場(chǎng)景里最常見的三類內(nèi)部命令問題第一mysql、mysqldump等命令不在 PATH 中。交互式終端里你敲mysql -u... -p... -e select 1能跑通是因?yàn)橛脩舻?bash_profile或.bashrc里加了 MySQL 的 bin 目錄。但腳本執(zhí)行時(shí)不一定繼承這個(gè)環(huán)境尤其是通過 cron、systemd timer、CI 任務(wù)來調(diào)度的時(shí)候。這時(shí)候 shell 會(huì)報(bào)mysql: command not found注意這個(gè)報(bào)錯(cuò)通常不是No such file or directory但人慌起來容易把兩者混為一談。第二重定向目標(biāo)目錄不存在。比如腳本里寫mysqldump ... /backup/$(date %F).sql而/backup目錄根本沒建shell 會(huì)報(bào)-bash: /backup/db_2025-01-01.sql: No such file or directory很多人誤以為 MySQL 沒起來實(shí)際就是目錄沒創(chuàng)建。第三讀取外部 SQL 文件時(shí)文件不存在比如mysql -uapp -p*** app_db /opt/sql/init.sql文件缺失時(shí)同樣報(bào)錯(cuò)。這個(gè)不用展開提醒一句就夠重定向前先mkdir -p并檢查源文件是否存在。用一套固定的定位流程能省很多時(shí)間# 1. 檢查腳本格式 file check_db.sh # 2. 語法與跟蹤 bash -n check_db.sh bash -x check_db.sh # 3. 查數(shù)據(jù)庫命令位置 which mysql echo $PATH2. 數(shù)據(jù)庫連接場(chǎng)景下“文件不存在”的隱藏根源2.1 socket 文件與連接配置的坑均勻排查完腳本自身真正的“數(shù)據(jù)庫相關(guān)文件不存在”才會(huì)浮出水面。其中第一個(gè)經(jīng)典坑是 MySQL 的 socket 文件?？蛻舳诉Blocalhost時(shí)默認(rèn)不走 TCP 網(wǎng)絡(luò)而是去讀 Unix socket 文件路徑通常約定為/tmp/mysql.sock或/var/run/mysqld/mysqld.sock。如果服務(wù)端的 socket 路徑和客戶端默認(rèn)路徑不一致或者客戶端通過--socket/custom/path/mysql.sock顯式指定了錯(cuò)誤路徑報(bào)錯(cuò)往往長(zhǎng)這樣ERROR 2002 (HY000): Cant connect to local MySQL server through socket /tmp/mysql.sock (2)這個(gè)(2)就是系統(tǒng)錯(cuò)誤碼 ENOENT對(duì)應(yīng)“No such file or directory”。很多人的第一反應(yīng)是 MySQL 服務(wù)沒啟動(dòng)systemctl status mysql查半天服務(wù)明明正常。真正的解法是確認(rèn) socket 文件的真實(shí)位置可以用find / -name *.sock 2/dev/null搜索或者在 MySQL 配置里查socket參數(shù)。腳本里推薦顯式指定 socket 路徑或者干脆用 TCP 方式連接-h 127.0.0.1繞開 socket 文件這個(gè)不確定性。如果只是為了跑查詢我個(gè)人的習(xí)慣是在腳本里加mysql --socket/tmp/mysql.sock -h localhost ...如果-h寫了127.0.0.1那么客戶端會(huì)強(qiáng)制走 TCP就不會(huì)有 socket 文件相關(guān)的報(bào)錯(cuò)。兩者選其一即可不要混著寫。2.2 SQL 文件導(dǎo)入導(dǎo)出時(shí)的路徑歧義前面提過重定向路徑但這里值得再展開一點(diǎn)因?yàn)閿?shù)據(jù)庫腳本里太常見了。比如說做每日備份BACKUP_DIR/data/backup mkdir -p $BACKUP_DIR mysqldump --single-transaction -uapp -p*** app_db $BACKUP_DIR/app_db_$(date %F).sql三步少一步都不行。有些腳本寫得很隨意沒建目錄直接重定向。目錄不存在時(shí) shell 在打開目標(biāo)文件之前就失敗了。反過來導(dǎo)入場(chǎng)景也一樣mysql -uapp -p*** app_db /tmp/import.sql/tmp/import.sql如果不存在想都不用想又是“No such file or directory”。這種問題定位很快但容易讓人誤入歧途跑去看數(shù)據(jù)庫權(quán)限。我建議腳本里統(tǒng)一使用變量保存路徑然后在執(zhí)行前做一次文件判斷SQL_FILE/opt/sql/init.sql if [[ ! -f $SQL_FILE ]]; then echo SQL file not found: $SQL_FILE 2 exit 1 fi mysql -uapp -p*** app_db $SQL_FILE這樣至少報(bào)錯(cuò)信息是自己寫的可讀性比 shell 原生的報(bào)錯(cuò)好太多。2.3 環(huán)境變量丟失與 cron 調(diào)度場(chǎng)景數(shù)據(jù)庫命令在交互式終端里能跑、在腳本里死活找不到這個(gè)“非交互環(huán)境”的坑在 crontab 里幾乎是必踩。cron 執(zhí)行腳本時(shí)環(huán)境變量基本是空的PATH只有系統(tǒng)默認(rèn)值。如果你的 MySQL 裝在/usr/local/mysql/bin那么 cron 里的腳本執(zhí)行mysql時(shí)就是找不到命令。最穩(wěn)妥的做法不是在 crontab 里寫一堆PATH而是在腳本開頭顯式設(shè)置export PATH/usr/local/mysql/bin:/usr/local/bin:/usr/bin:/bin同時(shí)有些腳本會(huì)依賴~/.my.cnf來存儲(chǔ)數(shù)據(jù)庫賬號(hào)密碼。cron 執(zhí)行時(shí)HOME不一定是你登錄用戶的 home 目錄密碼文件讀不到連接數(shù)據(jù)庫時(shí)就會(huì)跳出來交互式密碼提示然后腳本卡死。這個(gè)問題表面上是密碼錯(cuò)誤實(shí)際是環(huán)境變量和文件路徑問題和No such file同源。3. Shell函數(shù)傳參數(shù)組到底怎么傳才穩(wěn)3.1 數(shù)組直接傳函數(shù)的翻車現(xiàn)場(chǎng)數(shù)據(jù)庫腳本第一步搞定之后第二個(gè)高頻坑又在“函數(shù)封裝”上等著你。寫過一段時(shí)間 Shell 后你會(huì)發(fā)現(xiàn)查庫邏輯一旦變成“對(duì)一組庫批量執(zhí)行同樣的操作”自然就會(huì)想寫一個(gè)函數(shù)然后把數(shù)據(jù)庫名列表作為參數(shù)傳進(jìn)去。而數(shù)組傳參的坑基本是每個(gè)腳本人都會(huì)踩一遍的。先看典型的錯(cuò)誤寫法#!/bin/bash DB_LIST(order_db user_db log_db) check_db() { echo 第一個(gè)參數(shù): $1 echo 第二個(gè)參數(shù): $2 } check_db ${DB_LIST[]}這樣調(diào)用$1拿到order_db$2拿到user_db看起來好像沒問題。但函數(shù)內(nèi)部根本不知道數(shù)組一共有多少個(gè)元素如果數(shù)組是動(dòng)態(tài)生成的長(zhǎng)度不確定你要在函數(shù)里拿完整列表就得用$把所有位置參數(shù)重新收集一遍。這種做法有個(gè)嚴(yán)重的隱含風(fēng)險(xiǎn)一旦函數(shù)還需要接收其他業(yè)務(wù)參數(shù)數(shù)組元素和普通參數(shù)混在一起就再也分不清了。還有一種更隱蔽的翻車是用${DB_LIST}傳check_db ${DB_LIST}在 Bash 里${arr}等價(jià)于${arr[0]}只取第一個(gè)元素。如果數(shù)組有 100 個(gè)庫名函數(shù)里永遠(yuǎn)只看到第一個(gè)其余 99 個(gè)靜默丟失。這種錯(cuò)誤不會(huì)報(bào)任何錯(cuò)排查起來比報(bào)錯(cuò)坑得多因?yàn)檫壿嬌峡粗耆侠怼?.2 方案一展開傳參函數(shù)內(nèi)重建數(shù)組最直觀的兼容方案是調(diào)用時(shí)讓數(shù)組展開成獨(dú)立的多個(gè)參數(shù)函數(shù)內(nèi)部再重新收集成數(shù)組check_dbs() { local dbs($) for db in ${dbs[]}; do echo checking $db done } DB_LIST(order_db user_db log_db) check_dbs ${DB_LIST[]}關(guān)鍵點(diǎn)是雙引號(hào)不能丟。${DB_LIST[]}會(huì)保留每個(gè)元素中的空格而${DB_LIST[]}不帶引號(hào)則會(huì)被 shell 分詞一個(gè)元素可能被拆成兩個(gè)。函數(shù)內(nèi)部$同樣要加引號(hào)然后再賦值給數(shù)組。這個(gè)方案 Bash 3.x 也能用兼容性最好缺點(diǎn)是數(shù)組很大時(shí)參數(shù)列表會(huì)膨脹同函數(shù)里的其他普通參數(shù)也容易搞混。如果函數(shù)里還有其他普通參數(shù)我的建議是先傳普通參數(shù)再傳數(shù)組展開函數(shù)內(nèi)部用shift把普通參數(shù)消費(fèi)掉剩下的全部收進(jìn)數(shù)組check_dbs() { local mode$1 shift local dbs($) echo mode$mode, db count${#dbs[]} }3.3 方案二推薦傳數(shù)組名加 nameref 引用比展開傳參更優(yōu)雅的方式是直接傳數(shù)組的名字然后在函數(shù)內(nèi)建一個(gè)引用。Bash 4.3 引入了nameref用declare -n或者函數(shù)內(nèi)local -n聲明check_dbs() { local -n db_ref$1 for db in ${db_ref[]}; do echo checking $db done } DB_LIST(order_db user_db log_db) check_dbs DB_LIST調(diào)用方傳的是變量名字符串DB_LIST函數(shù)內(nèi)部local -n db_ref$1建立了一個(gè)引用之后訪問db_ref就等于訪問外部的DB_LIST。名字傳進(jìn)來數(shù)據(jù)不復(fù)制函數(shù)內(nèi)可以直接用${#db_ref[]}獲取長(zhǎng)度、按下標(biāo)訪問、甚至給數(shù)組追加元素。用這個(gè)方案有三個(gè)注意事項(xiàng)第一函數(shù)內(nèi)的引用變量名不能和傳入的數(shù)組名相同。如果外部數(shù)組叫db_ref函數(shù)內(nèi)部又用local -n db_ref$1Bash 會(huì)報(bào)circular name reference。建議函數(shù)內(nèi)部統(tǒng)一用_ref、_arr這類不太會(huì)和業(yè)務(wù)變量沖突的名字。第二nameref 是引用不是拷貝。函數(shù)內(nèi)給db_ref重新賦值會(huì)直接修改外部數(shù)組。如果只想讀取不要對(duì)引用變量做賦值操作如果想做副本可以在函數(shù)內(nèi)先復(fù)制一份local -a tmp_arr(${db_ref[]})第三需要確認(rèn)運(yùn)行環(huán)境 Bash 版本不低于 4.3。macOS 自帶的老版本 Bash 3.2 不支持declare -n這個(gè)改動(dòng)沒法用。生產(chǎn)環(huán)境建議統(tǒng)一維護(hù)一份較新的 bash或者用下面的兼容方案。3.4 方案三老版本 Bash 的兼容打法如果很倒霉線上環(huán)境是 Bash 3.x不能上nameref。退而求其次有兩種辦法。方法一是走全局變量數(shù)組定義在函數(shù)外函數(shù)內(nèi)直接引用配合注釋約定好職責(zé)。這個(gè)最簡(jiǎn)單但封裝性差函數(shù)不通用換個(gè)數(shù)組名就得改函數(shù)沒法做成公共函數(shù)庫。方法二是用eval做間接展開。思路是先拿到數(shù)組名再?gòu)臄?shù)組名反推出數(shù)組內(nèi)容check_dbs() { local arr_name$1 eval local dbs(\\${$arr_name[]}\) for db in ${dbs[]}; do echo checking $db done }這一行的含義是先在外面構(gòu)造一個(gè)字符串local dbs(${DB_LIST[]})然后讓eval在當(dāng)前位置執(zhí)行它等于把目標(biāo)數(shù)組復(fù)制成了函數(shù)內(nèi)的dbs。好處是函數(shù)內(nèi)后續(xù)操作都正常了壞處是eval對(duì)傳入的$1完全不設(shè)防。如果數(shù)組名來自外部輸入里面塞了一段惡意命令就會(huì)直接被 eval 執(zhí)行。所以這個(gè)方案只適合自己內(nèi)部明確可控的場(chǎng)景絕不建議對(duì)不可信的參數(shù)使用。3.5 三種方案怎么選做了張表方便生產(chǎn)環(huán)境直接對(duì)照方案Bash 版本要求數(shù)據(jù)復(fù)制主要風(fēng)險(xiǎn)推薦場(chǎng)景展開傳參 $重建3.x是普通參數(shù)和數(shù)組元素易混淆數(shù)組較小一次性腳本nameref 傳數(shù)組名4.3否circular name reference生產(chǎn)環(huán)境首選eval 間接展開3.x是命令注入風(fēng)險(xiǎn)老版本緊急兼容另外一個(gè)更省事的辦法如果你的數(shù)組只是循環(huán)遍歷其實(shí)不一定要傳進(jìn)函數(shù)。把for循環(huán)留在外層函數(shù)只接收單個(gè)元素比如check_db $db這就完全繞開數(shù)組傳參問題。很多場(chǎng)景下這種“函數(shù)處理單值 外層循環(huán)”的結(jié)構(gòu)比傳數(shù)組更清晰也更符合 KISS 原則。4. 實(shí)戰(zhàn)案例批量數(shù)據(jù)庫巡檢腳本的完整排查修復(fù)4.1 一個(gè)同時(shí)踩中兩個(gè)坑的典型腳本下面這個(gè)腳本組合了前文所有坑的精華你可以先體會(huì)一下#!/bin/bash HOST_LIST(10.0.0.1 10.0.0.2 10.0.0.3) check_cluster() { local first$1 echo 第一個(gè)主機(jī): $first mysql -h $first -uapp -psecret -e SELECT 1 21 } check_cluster ${HOST_LIST[]}這個(gè)腳本在部署過程中暴露了三個(gè)層級(jí)的錯(cuò)誤CRLF 引發(fā)的解釋器找不到、mysql 命令不在 PATH 里、數(shù)組傳參后函數(shù)里只拿到了第一個(gè)主機(jī)。前兩個(gè)報(bào)錯(cuò)是“No such file or directory”系的第三個(gè)是靜默邏輯錯(cuò)誤。4.2 從報(bào)錯(cuò)到修復(fù)的逐級(jí)排查先遇到的是第一個(gè)報(bào)錯(cuò)/bin/bash^M: bad interpreter。執(zhí)行file check_db.sh看到with CRLF line terminators用sed -i s/\r$// check_db.sh處理掉。再次執(zhí)行報(bào)錯(cuò)變成了mysql: command not found這說明腳本本身已經(jīng)能跑了但mysql命令沒被找到。which mysql沒有任何輸出說明 PATH 里不包含 MySQL bin 目錄。檢查發(fā)現(xiàn) MySQL 是編譯安裝在/usr/local/mysql下的交互式終端里能跑是因?yàn)?bash_profile里 export 了 PATH腳本運(yùn)行環(huán)境卻沒有。修復(fù)方式是在腳本開頭export PATH/usr/local/mysql/bin:$PATH第三個(gè)問題就是在功能驗(yàn)證時(shí)發(fā)現(xiàn)的。腳本執(zhí)行后循環(huán)并沒有報(bào)錯(cuò)但輸出里始終只顯示10.0.0.1。檢查了函數(shù)調(diào)用方式發(fā)現(xiàn)${HOST_LIST[]}展開后傳給函數(shù)按位置參數(shù)看$1就是第一個(gè)元素函數(shù)里只用了$1后面的主機(jī)全部被忽略。這里改成 nameref傳入數(shù)組名而不是展開內(nèi)容。4.3 修復(fù)后的完整可運(yùn)行版本修復(fù)之后的腳本長(zhǎng)這樣#!/bin/bash # 功能批量巡檢數(shù)據(jù)庫主機(jī)連通性 # 用法bash check_cluster.sh export PATH/usr/local/mysql/bin:/usr/local/bin:/usr/bin:/bin HOST_LIST(10.0.0.1 10.0.0.2 10.0.0.3) DB_USERapp_user DB_PASSapp_pass check_cluster() { local -n host_ref$1 local connect_timeout5 for host in ${host_ref[]}; do echo checking $host mysql --connect-timeout$connect_timeout \ -h $host \ -u$DB_USER -p$DB_PASS \ -e SELECT ok AS status; 21 \ || echo FAILED: $host done } main() { check_cluster HOST_LIST } main $這個(gè)版本有幾個(gè)細(xì)節(jié)值得說。第一數(shù)組按名字傳入用local -n host_ref$1綁定外部數(shù)組函數(shù)內(nèi)部循環(huán)遍歷時(shí)能拿到完整列表。第二mysql命令失敗時(shí)用|| echo FAILED兜底而不是直接讓腳本退出。這樣才能完整巡檢所有主機(jī)不會(huì)因?yàn)橐慌_(tái)故障中斷整批任務(wù)。第三腳本開頭顯式設(shè)置 PATH避免 cron 環(huán)境變量稀疏導(dǎo)致命令找不到。第四外層用main $包一層入口函數(shù)將來想通過命令行參數(shù)指定主機(jī)列表只需要在main里把$轉(zhuǎn)成數(shù)組再傳給函數(shù)即可改動(dòng)很小。如果后續(xù)需要在巡檢時(shí)同時(shí)傳入“主機(jī)列表”和“端口列表”兩個(gè)數(shù)組nameref 方案也能輕松擴(kuò)展check_cluster() { local -n host_ref$1 local -n port_ref$2 ... } check_cluster HOST_LIST PORT_LIST一次傳兩個(gè)名字也沒有參數(shù)拆分問題這就是傳名字比傳內(nèi)容的優(yōu)勢(shì)。5. 避坑手冊(cè)與經(jīng)驗(yàn)心得5.1 報(bào)錯(cuò)排查的固定四步走結(jié)合這次排查過程我把固定動(dòng)作總結(jié)成了四步先用file命令看腳本格式確認(rèn)有沒有 CRLF、BOM。這兩個(gè)問題就算你看一百遍源碼也看不出來只有工具能檢測(cè)。用bash -n做語法檢查再用bash -x跟蹤執(zhí)行定位報(bào)錯(cuò)發(fā)生的具體行。檢查依賴的外部命令路徑which mysql、which mysqldump在腳本開頭顯式 export PATH。數(shù)據(jù)庫層面的連接報(bào)錯(cuò)優(yōu)先看錯(cuò)誤碼和 socket 路徑區(qū)分 TCP 和 socket 兩種連接方式。特別是第一步我見過不少人在bad interpreter的報(bào)錯(cuò)下糾結(jié)了半小時(shí)最后把腳本刪了重寫。其實(shí)知道原理之后這只是一個(gè) 30 秒的修復(fù)。5.2 常見問題速查表報(bào)錯(cuò)現(xiàn)象根本原因定位方法修復(fù)手段/bin/bash^M: bad interpreter腳本行尾符是 CRLFfile script.sh看輸出dos2unix或sed -i s/\r$//mysql: command not foundMySQL bin 不在 PATHwhich mysql、echo $PATH腳本開頭export PATH或?qū)懰烂罱^對(duì)路徑ERROR 2002 (HY000) #2socket 文件不存在find / -name *.sock確認(rèn)路徑指定--socket或改-h 127.0.0.1走 TCP-bash: xxx.sql: No such file or directory導(dǎo)入文件或輸出目錄不存在ls -l、mkdir -p先建目錄、先檢查文件存在再執(zhí)行函數(shù)只拿到數(shù)組第一個(gè)元素${arr}只取下標(biāo) 0打印$#和所有參數(shù)用${arr[]}展開或傳數(shù)組名用 namerefcircular name referencenameref 與循環(huán)變量同名看報(bào)錯(cuò)行號(hào)內(nèi)部引用變量用獨(dú)立命名5.3 長(zhǎng)期有效的三條習(xí)慣第一個(gè)習(xí)慣編輯器統(tǒng)一配置 LF。我在 VSCode 里把默認(rèn)行尾符改成了 LF同時(shí)項(xiàng)目根目錄放.editorconfig寫腳本時(shí)end_of_line: lf直接固化。Git 倉(cāng)庫里再加.gitattributes聲明*.sh text eollf這樣團(tuán)隊(duì)協(xié)作時(shí)不管誰在什么系統(tǒng)上編輯提交到庫里都是 LF。第二個(gè)習(xí)慣寫函數(shù)前先想清楚參數(shù)協(xié)議。小數(shù)量參數(shù)用位置參數(shù)批量數(shù)據(jù)優(yōu)先傳數(shù)組名或用外層循環(huán)單值傳入。不要一邊寫一邊改協(xié)議否則函數(shù)越改越亂。第三個(gè)習(xí)慣公共腳本上線前過一遍 ShellCheck。這個(gè)工具能檢查出未加引號(hào)的變量、誤用eval、權(quán)限問題等大量隱患比人工 review 靠譜得多。我在實(shí)際處理這類問題時(shí)還保留了一個(gè)不算優(yōu)雅但很有效的習(xí)慣函數(shù)入口處臨時(shí)加一行調(diào)試輸出打印所有收到的參數(shù)個(gè)數(shù)和值。等確認(rèn)邏輯無誤再刪掉。看起來笨但對(duì)定位“以為傳了數(shù)組實(shí)際只傳了一個(gè)值”這種靜默問題比任何技巧都直接。這兩類坑本質(zhì)上都有共性Shell 腳本的邊界條件比想象中多報(bào)錯(cuò)信息往往指向的不是真正的問題函數(shù)參數(shù)的傳遞不像其他語言那么直白。理解了內(nèi)核加載腳本的方式、理解了 Bash 參數(shù)展開的語義再遇到它們就不會(huì)慌。我更推薦的方式是把這些經(jīng)驗(yàn)沉淀成自己的一份腳本模板開頭的 PATH 導(dǎo)出、函數(shù)傳參約定、錯(cuò)誤檢查邏輯全都固化進(jìn)去以后寫新腳本直接從模板抄實(shí)測(cè)下來比每次都從零開始省心得多。