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