写Shell脚本连数据库最怕的就是那种“上不着天、下不着地”的报错。它给你甩一句No such file or directory你顺着报错去找文件文件明明就在那儿你说它没道理吧它又确实带着你一路跑偏。我最近帮一个同事排查数据库巡检脚本就是这德行手动执行好好的一进crontab就挂日志里只留一行mysql: No such file or directory连个行号线索都不给。排查了大半天最后发现是脚本在Windows上编辑过换行符从LF变成了CRLF这个坑我已经不是第一次见了。同一天他又在群里问“Shell函数到底怎么把数组传进去”这两个问题看着八竿子打不着其实都是Shell这门语言的“性格缺陷”对环境极其敏感参数模型又极其简陋。这篇就把这两个高频坑放在一起聊透报错是怎么产生的、怎么定位、怎么修复以及函数传参数组的几种可行方案和它们各自的坑。适合刚入门Shell的读者也适合写脚本写了很多年、但一直被这两个问题反复折磨的老手可以直接当速查手册用。1. 问题拆解为什么这两个坑总是一起出现1.1 先分清“谁在报错”No such file or directory 的三种语境No such file or directory在Unix世界里几乎是“万能错误”的代名词它不是告诉你某个文件不存在那么简单而是有几种完全不同的语境处理方式也完全不同。我这些年被这个报错折磨过无数次最深的体会就是先搞清楚“谁在报”再去想“怎么修”。第一种语境是内核在找脚本解释器。你执行./test.sh内核读完第一行#!/bin/bash会去加载这个解释器路径。但如果脚本文件是Windows传过来的每行末尾多了个回车符\r内核实际找的是/bin/bash\r这个路径系统里当然没有于是报错bash: ./test.sh: /bin/bash^M: bad interpreter: No such file or directory注意关键词是“bad interpreter”。很多人看到No such file or directory就以为是脚本文件不存在接下来各种检查文件权限、路径、目录折腾半天。其实是解释器路径带了个看不见的\r。第二种语境是shell在PATH里找不到命令。脚本里写了mysql -h ...shell会按顺序在每个PATH目录里找mysql可执行文件。找不到就会报line 5: mysql: No such file or directory这条报错前面带了行号容易误以为“文件里第5行指向的某个文件不存在”。实际上就是PATH里没有mysql或者有mysql但当前环境变量很精简。最常见于crontab场景crontab默认PATH通常只有/usr/bin:/bin而mysql装在/usr/local/mysql/bin手动执行没问题一进定时任务就报这个错。第三种语境是动态链接库缺失。mysql可执行文件本身存在但它依赖的libmysqlclient.so找不到了运行时会报mysql: error while loading shared libraries: libmysqlclient.so.21: cannot open shared object file: No such file or directory这条也算No such file or directory但问题出在动态库搜索路径上跟PATH、跟脚本内容都没有关系。三条报错文本相似排查路径完全不同这是这个错误最迷惑人的地方。1.2 数组在Shell函数面前有多尴尬位置参数模型的局限数组传参问题其实是Shell函数设计模型的天然缺陷。传统编程语言里函数参数就是“值”传什么类型都行但Shell函数只有位置参数$1、$2…… 本质上全是字符串标量没有任何“容器”概念。你写func $arrShell并不认识这是一个数组它把$arr直接展开成${arr[0]}也就是数组的第一个元素。更离谱的是如果你写成func $arr[*]它会把所有元素用空格拼成一个字符串再传过去函数内部再想拆回来就难了——元素本身包含空格的话直接裂开。这两类问题的共同点是Shell是一门“看起来简单、用起来到处是暗坑”的语言。它跟Python、Java这类强类型、结构清晰的语言不一样脚本在执行前几乎不做任何类型检查报错信息又极不精确所以才会出现“报错说文件不存在实际是换行符不对”“传参数组丢失实际是参数模型不支持容器”这种反直觉的现象。理解了这层背景你就能明白为什么那么多老手反复强调Shell脚本与其说是“写”出来的不如说是“试”出来的排查能力比编码能力更重要。2. 数据库查询场景的“No such file or directory”实战排查2.1 四种常见根因对照表与诊断命令结合数据库场景我把带No such file or directory字眼的报错整理成了一张对照表这四类是实战中出现频率最高的报错形态根本原因首选诊断命令修复思路./test.sh: /bin/bash^M: bad interpreter脚本带CRLF换行符file test.shsed -i s/\r$// test.shline 7: mysql: No such file or directorymysql不在当前PATHtype -a mysql脚本内补PATH或写绝对路径mysql: error while loading shared libraries: libmysqlclient.so...动态库缺失ldd $(which mysql)安装依赖库或设置LD_LIBRARY_PATHmysql: [ERROR] Cant connect to local MySQL server through socket /var/run/mysqld/mysqld.sock (2)socket路径不存在或服务未启动ls -l /var/run/mysqld/mysqld.sock启动服务、调整socket路径或改用TCP连接这里特别说一下第四类。MySQL客户端连本地库默认走Unix socket报错末尾的(2)其实就是系统错误码ENOENT也就是No such file or directory。很多人在这一步开始怀疑人生“我明明装了mysql客户端啊”其实问题是服务端的socket文件没生成大概率是MySQL服务没启动或者启动时指定的socket路径跟客户端预期不一致。还有一个容易忽略的坑crontab和systemd环境下的PATH极简你手动在终端执行which mysql能找到路径不代表脚本执行时也能找到。排查这类问题不要凭印象直接在目标环境里跑一行echo $PATH看看实际值而不是用交互式shell的PATH来推测。2.2 一次完整排查实录从报错到修复我举一个接近真实的排查过程你照着这个流程走一遍以后遇到同类问题就有底气了。假设有个脚本db_check.sh内容大概是这样#!/bin/bash DB_NAMEorder_db mysql -u root -ppassword -e SELECT COUNT(*) FROM information_schema.tables WHERE table_schema${DB_NAME};直接执行./db_check.sh报错./db_check.sh: /bin/bash^M: bad interpreter: No such file or directory第一步用file命令确认文件类型file db_check.sh # 输出里有 with CRLF line terminators 字样到这里基本锁定了。再用head -1 db_check.sh | xxd看十六进制00000000: 2321 2f62 696e 2f62 6173 680d 0a #!/bin/bash..0d 0a就是CRLF的实锤正常Unix文件只有0a。修复命令sed -i s/\r$// db_check.sh修完再执行file db_check.sh确认没有CRLFbash -n db_check.sh做语法检查没问题之后再跑一次。如果脚本没带shebang用户直接bash db_check.sh执行CRLF坑的表现形式会变——shebang不参与但每一行命令名后面都跟着\r比如mysql\r报错变成mysql\r: command not found。这种叫“夹带私货”的错误最坑人肉眼完全看不出来必须用cat -A db_check.sh看行尾所有行尾显示^M$的就是有问题的行。还有一个我印象很深的案例脚本在某个环境正常换到另一台服务器就报mysql: No such file or directory。排查发现脚本开头没有设置PATH手动系统PATH里有/usr/local/mysql/bin但脚本执行时的PATH被某处覆盖了。最终在脚本开头加上一行export PATH${PATH}:/usr/local/mysql/bin:$(dirname $(readlink -f $(which mysql 2/dev/null) 2/dev/null) 2/dev/null)这样即使不清楚mysql具体装在哪也能动态取到它所在目录。3. 函数传参数组的三种方案与取舍3.1 方案横评全局变量、展开传参、nameref前面说了Shell位置参数天然不支持容器类型但需求摆在那儿总得有方案绕过去。我在生产环境里用得比较多的就三种全局变量法、展开传参法、nameref引用法。三者各有适用场景也各有暗坑。全局变量法是最简单粗暴的函数里直接引用外部数组变量名不需要传参。比如db_names(order_db user_db log_db) print_dbs() { for db in ${db_names[]}; do echo $db done }优点是零学习成本缺点是函数和全局状态强耦合脚本一长改一处变量名动全身很容易出“幽灵变量”。我建议只在单一脚本文件、函数不超过两三个的场景下用。展开传参法是很多教程推荐的入门写法print_dbs() { for db in $; do echo $db done } print_dbs ${db_names[]}核心是调用时用${db_names[]}把数组“拆”成多个独立参数函数内部$自然就拿到了完整列表。这个方案的优势是逻辑直观、跨版本兼容性好Bash 3都有缺点是第一函数如果还有普通参数顺序很混乱func some_flag ${arr[]}那你得知道$1是flag、$2到$#才是数组第二如果数组特别大展开后参数数量过多可能碰到ARG_MAX限制。nameref引用法是我现在最推荐的方式Bash 4.3 可用print_dbs() { local -n arr_ref$1 for db in ${arr_ref[]}; do echo $db done } db_names(order_db user_db log_db) print_dbs db_names调用时只传一个“数组名字符串”进去函数内部用local -n声明一个引用变量后续对该变量的操作会直接作用于原数组。这样语义最干净传多个数组也容易func arr1 arr2就是两次local -n。需要注意macOS自带的bash停留在3.2版本不支持这个特性生产环境要先用bash --version确认版本。3.2 完整示例连接数据库并批量统计表的行数我把三种方案揉进一个真实业务场景里有多个数据库逐个连上去查表总数。先看用nameref的完整写法#!/bin/bash set -euo pipefail export PATH${PATH}:/usr/local/mysql/bin DB_HOST${DB_HOST:-127.0.0.1} DB_USER${DB_USER:-root} DB_PASS${DB_PASS:-} db_names(order_db user_db log_db report_db) count_tables() { local -n dbs$1 local db cnt for db in ${dbs[]}; do cnt$(mysql -h${DB_HOST} -u${DB_USER} -p${DB_PASS} -N -e \ SELECT COUNT(*) FROM information_schema.tables WHERE table_schema${db}; 2/dev/null || true) if [[ -z $cnt ]]; then printf %-12s 连接失败或查询失败\n $db else printf %-12s %s 张表\n $db $cnt fi done } count_tables db_names这段代码里有几个细节我有意处理过。第一local -n dbs$1这里的dbs是局部引用名如果外部数组也叫dbsBash会报circular name reference。所以我建议局部引用变量带明显前缀比如_dbs_ref、arr_ref从命名上绕开冲突。第二mysql输出后面加了|| true是为了防止set -e在连接失败时直接把脚本退出——你需要在脚本里展示排查信息而不是静默终止。第三密码用${DB_PASS:-}从环境变量读避免硬编码在脚本里。如果传两个数组比如一个库名列表、一个阈值列表写法是check_threshold() { local -n _dbs_ref$1 local -n _thr_ref$2 for db in ${_dbs_ref[]}; do echo ${db} 的阈值是 ${_thr_ref[$db]:-未设置} done }调用时写check_threshold db_names thr_map。这时候local -n的优势就完全体现出来了展开传参法在这种“两个数组搭配使用”的场景下会很难受你得小心翼翼地维护两个$的切片关系。如果只能用兼容性方案我建议用展开传参法写一个辅助函数专门处理“单参数列表 数组”print_with_flag() { local flag$1 shift for db in $; do printf %s - %s\n $flag $db done } print_with_flag checking ${db_names[]}核心技巧是先shift把$1从参数列表里挪出去剩下的$就全是数组元素了。4. 高频问题速查与独家避坑笔记4.1 六个高频问题一表速查我在不同团队、不同项目里来回踩坑之后把最常遇到的问题浓缩成了一张速查表。排查的时候先从现象入手去表里找对应行能少走很多弯路现象根本原因快速定位命令处理方式./test.sh: /bin/bash^M: bad interpreter脚本是CRLF换行file test.shsed -i s/\r$// test.shline 7: mysql: No such file or directorymysql不在脚本执行环境PATHtype -a mysql脚本开头补PATH或写绝对路径脚本能跑但数据库报(2)连接异常socket文件未生成ls -l /var/run/mysqld/mysqld.sock启动MySQL服务或指定socket参数函数里echo ${arr[]}只有一个元素直接传的是数组名没加展开函数内打印$#看参数个数调用时写${arr[]}或用namereflocal -n: circular name reference引用变量和外部变量同名检查函数内local变量名改名带_ref/_tmp前缀脚本在crontab里找不到mysqlcrontab环境PATH精简crontab里echo $PATH /tmp/path.txt脚本开头export PATH...这张表里我想特别强调第一行和第六行这两个是我实际工作中遇到频率最高的。第一行是因为很多人开发环境是Windows写完脚本不经过格式转换直接传到Linux服务器踩一次踩两次还是有人继续踩第六行则是“手动执行没问题、定时任务就出错”的头号元凶排查时一定要站在“脚本即将运行的环境”去思考而不是你当前终端的环境。4.2 我踩过坑之后养成的三个习惯第一个习惯每写一个Shell脚本先过三道“安检”。第一道是file 脚本名确认换行符是LF而不是CRLF第二道是bash -n 脚本名做纯语法检查第三道是shellcheck 脚本名用这个静态分析工具检查变量引用、引号使用这些细节问题。shellcheck能抓出一堆肉眼难发现的坑比如${arr[]}没加引号导致词分割、该用local却没用的变量泄漏非常值得养成习惯。第二个习惯所有需要传数组的Shell函数统一用nameref方案并加_ref后缀。全局变量法不是不能用但脚本维护到后期变量间的隐式依赖会让人崩溃。用local -n之后函数签名一眼就能看出它依赖哪些外部变量阅读代码的成本低很多。当然这个习惯的前提是Bash版本在4.3以上老系统上我会规避掉所有数组传参需求改用“先拼接、后读取”的折中写法。第三个习惯数据库脚本里绝不硬编码连接信息。密码直接写在脚本里一是容易被同事一眼看到二是换一次密码要改好几个地方三是版本管理时会污染代码仓库。我现在的做法是通过环境变量注入调用时这样用DB_USERroot DB_PASSXXX ./db_check.sh脚本内部读取 ${DB_USER:-} 和${DB_PASS:-}没有设置就先给出清晰提示再退出。这样既安全也方便别人理解脚本的运行前提。另外还有一个小细节新手经常忽略在函数里使用local声明局部变量能避免污染全局命名空间。结合local -n的时候要格外当心比如print_arr() { local -n arr_ref$1 local arr # 这里的 arr 和引用名不同即可 for arr in ${arr_ref[]}; do echo $arr done }循环变量和引用变量取不同的名字就不会触发循环引用。类似的土办法很多核心思路是一样的local -n本质上只是一个“别名”不是拷贝用的时候心里要清楚你操作的就是原来那个数组而不是它的副本。如果你希望函数内部修改数组但不影响外部就得先显式拷贝一份copy_array() { local -n _src$1 local -n _dst$2 _dst(${_src[]}) }这种“引用传址”和“值拷贝”的区分刚接触时容易混我在项目里反复撞过几次之后才总结出上面的写法。最后再分享一个排查技巧遇到奇怪的Shell报错别光盯着报错文本看先用bash -x script.sh跑一遍输出里会显示每一步的命令展开过程。很多时候问题在 “执行到某一行命令突然消失” 的时候就已经暴露了。
写Shell脚本连数据库最怕的就是那种“上不着天、下不着地”的报错。它给你甩一句No such file or directory你顺着报错去找文件文件明明就在那儿你说它没道理吧它又确实带着你一路跑偏。我最近帮一个同事排查数据库巡检脚本就是这德行手动执行好好的一进crontab就挂日志里只留一行mysql: No such file or directory连个行号线索都不给。排查了大半天最后发现是脚本在Windows上编辑过换行符从LF变成了CRLF这个坑我已经不是第一次见了。同一天他又在群里问“Shell函数到底怎么把数组传进去”这两个问题看着八竿子打不着其实都是Shell这门语言的“性格缺陷”对环境极其敏感参数模型又极其简陋。这篇就把这两个高频坑放在一起聊透报错是怎么产生的、怎么定位、怎么修复以及函数传参数组的几种可行方案和它们各自的坑。适合刚入门Shell的读者也适合写脚本写了很多年、但一直被这两个问题反复折磨的老手可以直接当速查手册用。1. 问题拆解为什么这两个坑总是一起出现1.1 先分清“谁在报错”No such file or directory 的三种语境No such file or directory在Unix世界里几乎是“万能错误”的代名词它不是告诉你某个文件不存在那么简单而是有几种完全不同的语境处理方式也完全不同。我这些年被这个报错折磨过无数次最深的体会就是先搞清楚“谁在报”再去想“怎么修”。第一种语境是内核在找脚本解释器。你执行./test.sh内核读完第一行#!/bin/bash会去加载这个解释器路径。但如果脚本文件是Windows传过来的每行末尾多了个回车符\r内核实际找的是/bin/bash\r这个路径系统里当然没有于是报错bash: ./test.sh: /bin/bash^M: bad interpreter: No such file or directory注意关键词是“bad interpreter”。很多人看到No such file or directory就以为是脚本文件不存在接下来各种检查文件权限、路径、目录折腾半天。其实是解释器路径带了个看不见的\r。第二种语境是shell在PATH里找不到命令。脚本里写了mysql -h ...shell会按顺序在每个PATH目录里找mysql可执行文件。找不到就会报line 5: mysql: No such file or directory这条报错前面带了行号容易误以为“文件里第5行指向的某个文件不存在”。实际上就是PATH里没有mysql或者有mysql但当前环境变量很精简。最常见于crontab场景crontab默认PATH通常只有/usr/bin:/bin而mysql装在/usr/local/mysql/bin手动执行没问题一进定时任务就报这个错。第三种语境是动态链接库缺失。mysql可执行文件本身存在但它依赖的libmysqlclient.so找不到了运行时会报mysql: error while loading shared libraries: libmysqlclient.so.21: cannot open shared object file: No such file or directory这条也算No such file or directory但问题出在动态库搜索路径上跟PATH、跟脚本内容都没有关系。三条报错文本相似排查路径完全不同这是这个错误最迷惑人的地方。1.2 数组在Shell函数面前有多尴尬位置参数模型的局限数组传参问题其实是Shell函数设计模型的天然缺陷。传统编程语言里函数参数就是“值”传什么类型都行但Shell函数只有位置参数$1、$2…… 本质上全是字符串标量没有任何“容器”概念。你写func $arrShell并不认识这是一个数组它把$arr直接展开成${arr[0]}也就是数组的第一个元素。更离谱的是如果你写成func $arr[*]它会把所有元素用空格拼成一个字符串再传过去函数内部再想拆回来就难了——元素本身包含空格的话直接裂开。这两类问题的共同点是Shell是一门“看起来简单、用起来到处是暗坑”的语言。它跟Python、Java这类强类型、结构清晰的语言不一样脚本在执行前几乎不做任何类型检查报错信息又极不精确所以才会出现“报错说文件不存在实际是换行符不对”“传参数组丢失实际是参数模型不支持容器”这种反直觉的现象。理解了这层背景你就能明白为什么那么多老手反复强调Shell脚本与其说是“写”出来的不如说是“试”出来的排查能力比编码能力更重要。2. 数据库查询场景的“No such file or directory”实战排查2.1 四种常见根因对照表与诊断命令结合数据库场景我把带No such file or directory字眼的报错整理成了一张对照表这四类是实战中出现频率最高的报错形态根本原因首选诊断命令修复思路./test.sh: /bin/bash^M: bad interpreter脚本带CRLF换行符file test.shsed -i s/\r$// test.shline 7: mysql: No such file or directorymysql不在当前PATHtype -a mysql脚本内补PATH或写绝对路径mysql: error while loading shared libraries: libmysqlclient.so...动态库缺失ldd $(which mysql)安装依赖库或设置LD_LIBRARY_PATHmysql: [ERROR] Cant connect to local MySQL server through socket /var/run/mysqld/mysqld.sock (2)socket路径不存在或服务未启动ls -l /var/run/mysqld/mysqld.sock启动服务、调整socket路径或改用TCP连接这里特别说一下第四类。MySQL客户端连本地库默认走Unix socket报错末尾的(2)其实就是系统错误码ENOENT也就是No such file or directory。很多人在这一步开始怀疑人生“我明明装了mysql客户端啊”其实问题是服务端的socket文件没生成大概率是MySQL服务没启动或者启动时指定的socket路径跟客户端预期不一致。还有一个容易忽略的坑crontab和systemd环境下的PATH极简你手动在终端执行which mysql能找到路径不代表脚本执行时也能找到。排查这类问题不要凭印象直接在目标环境里跑一行echo $PATH看看实际值而不是用交互式shell的PATH来推测。2.2 一次完整排查实录从报错到修复我举一个接近真实的排查过程你照着这个流程走一遍以后遇到同类问题就有底气了。假设有个脚本db_check.sh内容大概是这样#!/bin/bash DB_NAMEorder_db mysql -u root -ppassword -e SELECT COUNT(*) FROM information_schema.tables WHERE table_schema${DB_NAME};直接执行./db_check.sh报错./db_check.sh: /bin/bash^M: bad interpreter: No such file or directory第一步用file命令确认文件类型file db_check.sh # 输出里有 with CRLF line terminators 字样到这里基本锁定了。再用head -1 db_check.sh | xxd看十六进制00000000: 2321 2f62 696e 2f62 6173 680d 0a #!/bin/bash..0d 0a就是CRLF的实锤正常Unix文件只有0a。修复命令sed -i s/\r$// db_check.sh修完再执行file db_check.sh确认没有CRLFbash -n db_check.sh做语法检查没问题之后再跑一次。如果脚本没带shebang用户直接bash db_check.sh执行CRLF坑的表现形式会变——shebang不参与但每一行命令名后面都跟着\r比如mysql\r报错变成mysql\r: command not found。这种叫“夹带私货”的错误最坑人肉眼完全看不出来必须用cat -A db_check.sh看行尾所有行尾显示^M$的就是有问题的行。还有一个我印象很深的案例脚本在某个环境正常换到另一台服务器就报mysql: No such file or directory。排查发现脚本开头没有设置PATH手动系统PATH里有/usr/local/mysql/bin但脚本执行时的PATH被某处覆盖了。最终在脚本开头加上一行export PATH${PATH}:/usr/local/mysql/bin:$(dirname $(readlink -f $(which mysql 2/dev/null) 2/dev/null) 2/dev/null)这样即使不清楚mysql具体装在哪也能动态取到它所在目录。3. 函数传参数组的三种方案与取舍3.1 方案横评全局变量、展开传参、nameref前面说了Shell位置参数天然不支持容器类型但需求摆在那儿总得有方案绕过去。我在生产环境里用得比较多的就三种全局变量法、展开传参法、nameref引用法。三者各有适用场景也各有暗坑。全局变量法是最简单粗暴的函数里直接引用外部数组变量名不需要传参。比如db_names(order_db user_db log_db) print_dbs() { for db in ${db_names[]}; do echo $db done }优点是零学习成本缺点是函数和全局状态强耦合脚本一长改一处变量名动全身很容易出“幽灵变量”。我建议只在单一脚本文件、函数不超过两三个的场景下用。展开传参法是很多教程推荐的入门写法print_dbs() { for db in $; do echo $db done } print_dbs ${db_names[]}核心是调用时用${db_names[]}把数组“拆”成多个独立参数函数内部$自然就拿到了完整列表。这个方案的优势是逻辑直观、跨版本兼容性好Bash 3都有缺点是第一函数如果还有普通参数顺序很混乱func some_flag ${arr[]}那你得知道$1是flag、$2到$#才是数组第二如果数组特别大展开后参数数量过多可能碰到ARG_MAX限制。nameref引用法是我现在最推荐的方式Bash 4.3 可用print_dbs() { local -n arr_ref$1 for db in ${arr_ref[]}; do echo $db done } db_names(order_db user_db log_db) print_dbs db_names调用时只传一个“数组名字符串”进去函数内部用local -n声明一个引用变量后续对该变量的操作会直接作用于原数组。这样语义最干净传多个数组也容易func arr1 arr2就是两次local -n。需要注意macOS自带的bash停留在3.2版本不支持这个特性生产环境要先用bash --version确认版本。3.2 完整示例连接数据库并批量统计表的行数我把三种方案揉进一个真实业务场景里有多个数据库逐个连上去查表总数。先看用nameref的完整写法#!/bin/bash set -euo pipefail export PATH${PATH}:/usr/local/mysql/bin DB_HOST${DB_HOST:-127.0.0.1} DB_USER${DB_USER:-root} DB_PASS${DB_PASS:-} db_names(order_db user_db log_db report_db) count_tables() { local -n dbs$1 local db cnt for db in ${dbs[]}; do cnt$(mysql -h${DB_HOST} -u${DB_USER} -p${DB_PASS} -N -e \ SELECT COUNT(*) FROM information_schema.tables WHERE table_schema${db}; 2/dev/null || true) if [[ -z $cnt ]]; then printf %-12s 连接失败或查询失败\n $db else printf %-12s %s 张表\n $db $cnt fi done } count_tables db_names这段代码里有几个细节我有意处理过。第一local -n dbs$1这里的dbs是局部引用名如果外部数组也叫dbsBash会报circular name reference。所以我建议局部引用变量带明显前缀比如_dbs_ref、arr_ref从命名上绕开冲突。第二mysql输出后面加了|| true是为了防止set -e在连接失败时直接把脚本退出——你需要在脚本里展示排查信息而不是静默终止。第三密码用${DB_PASS:-}从环境变量读避免硬编码在脚本里。如果传两个数组比如一个库名列表、一个阈值列表写法是check_threshold() { local -n _dbs_ref$1 local -n _thr_ref$2 for db in ${_dbs_ref[]}; do echo ${db} 的阈值是 ${_thr_ref[$db]:-未设置} done }调用时写check_threshold db_names thr_map。这时候local -n的优势就完全体现出来了展开传参法在这种“两个数组搭配使用”的场景下会很难受你得小心翼翼地维护两个$的切片关系。如果只能用兼容性方案我建议用展开传参法写一个辅助函数专门处理“单参数列表 数组”print_with_flag() { local flag$1 shift for db in $; do printf %s - %s\n $flag $db done } print_with_flag checking ${db_names[]}核心技巧是先shift把$1从参数列表里挪出去剩下的$就全是数组元素了。4. 高频问题速查与独家避坑笔记4.1 六个高频问题一表速查我在不同团队、不同项目里来回踩坑之后把最常遇到的问题浓缩成了一张速查表。排查的时候先从现象入手去表里找对应行能少走很多弯路现象根本原因快速定位命令处理方式./test.sh: /bin/bash^M: bad interpreter脚本是CRLF换行file test.shsed -i s/\r$// test.shline 7: mysql: No such file or directorymysql不在脚本执行环境PATHtype -a mysql脚本开头补PATH或写绝对路径脚本能跑但数据库报(2)连接异常socket文件未生成ls -l /var/run/mysqld/mysqld.sock启动MySQL服务或指定socket参数函数里echo ${arr[]}只有一个元素直接传的是数组名没加展开函数内打印$#看参数个数调用时写${arr[]}或用namereflocal -n: circular name reference引用变量和外部变量同名检查函数内local变量名改名带_ref/_tmp前缀脚本在crontab里找不到mysqlcrontab环境PATH精简crontab里echo $PATH /tmp/path.txt脚本开头export PATH...这张表里我想特别强调第一行和第六行这两个是我实际工作中遇到频率最高的。第一行是因为很多人开发环境是Windows写完脚本不经过格式转换直接传到Linux服务器踩一次踩两次还是有人继续踩第六行则是“手动执行没问题、定时任务就出错”的头号元凶排查时一定要站在“脚本即将运行的环境”去思考而不是你当前终端的环境。4.2 我踩过坑之后养成的三个习惯第一个习惯每写一个Shell脚本先过三道“安检”。第一道是file 脚本名确认换行符是LF而不是CRLF第二道是bash -n 脚本名做纯语法检查第三道是shellcheck 脚本名用这个静态分析工具检查变量引用、引号使用这些细节问题。shellcheck能抓出一堆肉眼难发现的坑比如${arr[]}没加引号导致词分割、该用local却没用的变量泄漏非常值得养成习惯。第二个习惯所有需要传数组的Shell函数统一用nameref方案并加_ref后缀。全局变量法不是不能用但脚本维护到后期变量间的隐式依赖会让人崩溃。用local -n之后函数签名一眼就能看出它依赖哪些外部变量阅读代码的成本低很多。当然这个习惯的前提是Bash版本在4.3以上老系统上我会规避掉所有数组传参需求改用“先拼接、后读取”的折中写法。第三个习惯数据库脚本里绝不硬编码连接信息。密码直接写在脚本里一是容易被同事一眼看到二是换一次密码要改好几个地方三是版本管理时会污染代码仓库。我现在的做法是通过环境变量注入调用时这样用DB_USERroot DB_PASSXXX ./db_check.sh脚本内部读取 ${DB_USER:-} 和${DB_PASS:-}没有设置就先给出清晰提示再退出。这样既安全也方便别人理解脚本的运行前提。另外还有一个小细节新手经常忽略在函数里使用local声明局部变量能避免污染全局命名空间。结合local -n的时候要格外当心比如print_arr() { local -n arr_ref$1 local arr # 这里的 arr 和引用名不同即可 for arr in ${arr_ref[]}; do echo $arr done }循环变量和引用变量取不同的名字就不会触发循环引用。类似的土办法很多核心思路是一样的local -n本质上只是一个“别名”不是拷贝用的时候心里要清楚你操作的就是原来那个数组而不是它的副本。如果你希望函数内部修改数组但不影响外部就得先显式拷贝一份copy_array() { local -n _src$1 local -n _dst$2 _dst(${_src[]}) }这种“引用传址”和“值拷贝”的区分刚接触时容易混我在项目里反复撞过几次之后才总结出上面的写法。最后再分享一个排查技巧遇到奇怪的Shell报错别光盯着报错文本看先用bash -x script.sh跑一遍输出里会显示每一步的命令展开过程。很多时候问题在 “执行到某一行命令突然消失” 的时候就已经暴露了。
