2026/9/10 8:56:39
FEATURED · 精选文章 
Shell这三字看着简单但不少人在真正上手写脚本的时候卡在了同一个地方单个命令都会组合起来就懵。更别提参数处理、循环分支、异常排查这些东西零散学过一点真到写一个能用的脚本时还是不知道怎么搭骨架。这次借这组Shell三部曲我按自己的实操习惯把从入门到能独立写脚本的全过程重新梳理了一遍不堆概念直接讲清楚每一部里必须掌握的核心逻辑和常见坑希望能帮你少走点弯路。1. 第一部曲变量、参数与解析——先把地基打牢这一部解决的是脚本的“骨架”问题。很多人写脚本是从“命令行能跑”直接跳到“写个文件执行”中间漏掉了一整块内容——脚本和命令行的本质区别在于脚本需要你把输入、输出、参数这三样东西理清楚。1.1 从第一行到“能跑”中间隔着的不是命令是执行方式我知道很多人的第一个脚本长这样echo hello world然后在终端里执行bash test.sh看到输出就觉得“会写脚本了”。这没错但离真正的“脚本思维”还差一层。我建议你把脚本当成一个独立的程序来看待而不是“一堆命令的堆叠”。一个规范的脚本开头应该包含这几样东西#!/usr/bin/env bash # # 脚本用途描述 # 作者、日期、版本 # set -euo pipefail其中shebang#!那行指定了解释器set -euo pipefail这段值得单独讲讲因为它几乎是我见过最实用的一组脚本保护开关-e脚本中任何一条命令返回非零状态码时立即退出避免“前面失败了后面还在继续跑”的雪崩式问题。-u使用未定义的变量直接报错退出这个对排查拼写错误极其有效。-o pipefail管道中任何一个命令失败整个管道的返回状态就是失败的否则管道只认最后一个命令的状态。我用一个真实的例子说明一下为什么这三样组合起来非常重要。假设你写了一条这样的命令cat /tmp/data.txt | grep error | wc -l如果/tmp/data.txt不存在cat已经失败了但grep还是会执行wc -l还是会输出一个数字。你看到屏幕上有个0以为是“没有匹配到error”其实是“文件根本没读到”。开了pipefail之后这条命令会直接报错退出你才知道问题出在哪。类似的坑配合set -u能拦截掉很多变量名写错的情况比如$flie这种拼写错误没开-u的话它只是安静地展开成一个空字符串后续逻辑全错还很难查。1.2 变量展开的隐藏细节引号、特殊参数和常见误用写Shell脚本变量展开是绕不开的核心。这里想重点聊几个高频出问题的点。变量与引号namehello world echo $name # 输出 hello world但分词word splitting已经发生了 echo $name # 输出 hello world作为一个整体如果name的值是带空格的路径比如/data/my files/不加引号就可能被拆成两个参数。我在实际工作中见过太多因为没加引号导致的线上问题所以有一个习惯性的建议在绝大多数场景下变量展开都加上双引号除非你明确需要分词比如for i in $list这种刻意为之的场景。位置参数和特殊变量特殊变量含义实际用途$0脚本本身的文件名写日志或帮助信息时用$#传入参数的数量校验至少需要几个参数$所有参数每个都作为独立个体遍历参数时用$*所有参数合并成一个字符串想整体传递所有参数时用$?上一条命令的退出码判断命令是否成功$$当前进程的PID生成临时文件名时防冲突这里最容易犯错的是$和$*的区别。直接看这个例子#!/usr/bin/env bash print_args() { for arg in $; do echo 参数: $arg done } print_args hello world second用$时输出两行分别是hello world和second。但如果把$换成$*只会输出一行hello world second。很多人在写“遍历所有参数”的脚本时用了$*结果带空格的参数全部被拆散调试半天才发现是引号和$/$*的差异导致的。还有$?的使用时机问题它只保留上一条命令的状态一旦你执行了其他命令旧的状态就被覆盖了。所以如果需要保存某个命令的退出状态第一时间存进变量if grep -q pattern file.txt; then status$? echo 状态已保存: $status fi1.3 命令替换与算术展开不是“能算数”就行Shell脚本里经常需要把命令的输出赋给变量这就是命令替换today$(date %Y-%m-%d) file_count$(ls /tmp | wc -l)注意这里用的是$(...)我建议完全不用剥引号包裹的反引号...风格因为反引号在处理嵌套和转义时非常痛苦$(...)可以嵌套使用可读性好得多。算术运算也是一样$((...))是标准写法里面的变量名可以不加$前缀i1 next$((i 1)) echo $next很多初学者会用expr或者更糟用let但在现代Shell里$((...))才是简洁且不易出错的方式。如果需要浮点数计算那就要用bc或awk了但那是另一个话题。2. 第二部曲循环、分支与函数——让脚本长出四肢骨架有了接下来是四肢。这一部是脚本从“单行道”变成“立交桥”的关键。搜索热词里有不少“shell脚本for循环”“shell的shift命令”相关的查询可见大家对这些控制流的理解还停留在“看过没写过”的程度。2.1 for循环最被低估的一种遍历方式for循环看起来人尽皆知但真到实战里很多人只会一种写法for i in 1 2 3 4 5; do echo $i done但这个写法只是for的冰山一角。实际工作中更常用的几种形态遍历文件列表for file in /var/log/*.log; do echo 处理: $file done这里有一个非常值得注意的坑当目录下没有匹配的.log文件时/var/log/*.log不会被展开而是作为一个字面字符串传给循环。这意味着$file会变成/var/log/*.log这个不存在的路径。所以安全写法是加上一个判断for file in /var/log/*.log; do [ -e $file ] || continue echo 处理: $file doneC风格循环精确控制次数for ((i 0; i 10; i)); do echo 第 $i 次 done这个特别适合处理数字逻辑比seq命令生成列表再遍历要快也更清晰。遍历带空格的文件名最优雅的方案是利用find配合while循环而不是forfind /data -name *.txt -print0 | while IFS read -r -d line; do echo 文件: $line done-print0和-d 配套使用用空字符而不是换行来分隔文件名这样文件名再奇葩包含空格、换行也不会出错。这里IFS是防止read把行首尾的空格吃掉-r防止反斜杠被转义解释。这套组合建议直接记下来。2.2 条件判断test、[]和[[ ]]的差别真不是玄学条件判断是脚本逻辑的分流阀。你可能见过if [ $a b ]也见过if [[ $a b ]]但未必清楚它们之间的关系。[ ]其实是test命令的语法糖衣[是一个独立的可执行文件不信可以在终端里输入type -a [看看。所以[里的变量需要加引号否则空变量或带空格的变量会让表达式出错。[[ ]]则是Shell内置的关键字不是外部命令。它的优势是支持和||逻辑运算而[ ]里只能写-a和-o不够直观且已不推荐支持正则匹配~变量即使不带引号也不会因为空格而拆词支持模式匹配在[[ ]]里右侧可以包含通配符做个对比strhello world if [ $str hello ]; then # 会报错参数太多 ... fi if [ $str hello ]; then # 正确但写法繁琐 ... fi if [[ $str *world* ]]; then # 支持通配符匹配非常方便 ... fi我现在写脚本的条件判断几乎一律用[[ ]]只有在必须兼容POSIX sh比如某些嵌入式环境里只有/bin/sh时才用[ ]。2.3 函数与返回值别用echo传结果Shell函数和大多数语言里函数的“返回”概念不太一样。Shell函数的返回值是退出状态码0到255而不是任意数据。所以想从函数返回一个字符串通常有两种做法用echo输出调用方用$(函数名)捕获用全局变量第一种更通用但有个需要注意的地方函数里的日志输出和结果输出要分开。看这个反例get_ip() { echo 开始获取IP... # 这行日志不能出现在结果里 hostname -I | awk {print $1} } ip$(get_ip) echo IP is: $ip你得到的$ip不是IP而是开始获取IP...和IP拼在一起的字符串。所以一个有经验的写法是把日志输出到标准错误stderrget_ip() { echo 开始获取IP... 2 hostname -I | awk {print $1} }调用方拿到的stdout就是干净的结果日志也还能看到。函数定义方面可以在函数体内用local声明局部变量这能大大降低函数之间的变量名冲突问题process_file() { local filename$1 local tmpfile tmpfile/tmp/$(basename $filename).$$.tmp # 这里即使有变量叫 filename也不会影响全局的同名变量 }2.4 shift命令参数解析的隐藏利器搜索热词里出现了“shell的shift命令”这确实是很多人忽略但实战价值很高的命令。shift的作用是把位置参数左移$2变成$1$3变成$2同时$#减一。配合while循环可以优雅地解析带选项的命令行参数。举个例子你希望脚本支持这种调用方式./script.sh -f config.ini -v --output out.txt用shift可以这样写#!/usr/bin/env bash verbose0 config output while [ $# -gt 0 ]; do case $1 in -f) config$2 shift 2 ;; -v) verbose1 shift ;; --output) output$2 shift 2 ;; *) echo 未知参数: $1 2 exit 1 ;; esac done echo config$config, verbose$verbose, output$output这种方式比手工一个参数一个参数去判断清晰得多而且扩展起来非常方便。shift 2表示左移两个位置这样$1就指向了下一个选项。注意shift数字不能超过$#否则Shell会报语法错误——所以while [ $# -gt 0 ]这个条件实际上是保护也是循环正常终止的关键。另外有个细节shift本身也会返回状态码就算你写成shift 5而只剩3个参数它不会报错只是会把所有参数都移完并把$#变成0。实测中更安全的做法是通过$#判断后再shift。3. 第三部曲文件操作与调试——脚本落地时真正的拦路虎前面两部分把语法和逻辑讲得差不多了但脚本“写出来”和“能安全地用起来”之间还有一段路要趟。这一段我拿搜索热词里出现频率很高的“linux用shell重命名文件”和“shell中常见坑”来展开这些都是真实场景中最容易翻车的地方。3.1 批量重命名一个mv命令藏了多少细节很多人看到“重命名文件”第一反应就是mv old new这是对的。但批量重命名才是实战里的高频需求比如把目录下所有*.JPG改成*.jpg、把report_2025.txt改成report_2026.txt。最基本的改名就是mv加引号mv report 2025.txt report 2026.txt但批量的时候新手最容易踩的坑是直接把for循环里的变量拼到新文件名中却忘了处理扩展名和路径前缀。下面这段代码就是一个经典的反面教材# 错误示范默认当前目录却忘记去掉路径前缀 for file in /data/images/*.JPG; do mv $file $(basename $file .JPG).jpg done咦这里只改了后缀看起来没问题其实有一个非常隐蔽的细节$(basename $file .JPG).jpg编辑后只剩文件名没有目录前缀所以mv会把新文件生成到当前工作目录而不是/data/images/目录下。你需要的是for file in /data/images/*.JPG; do dir$(dirname $file) name$(basename $file .JPG) mv $file $dir/$name.jpg done这个坑我踩过不止一次因为mv跨目录移动时目标路径没有目录前缀导致文件全部散落到当前目录后面还得手动搬回去。如果是更复杂的重命名规则比如替换文件名中的特定字符串可以用Shell的参数扩展newname${file/old/new}这行命令把$file中第一个匹配old的部分替换为new。配合批量循环比用sed再拼接要快。3.2 常见坑的完整排查链路以“for循环里管道失效”为例搜索热词里有“shell中常见坑”这是个好信号说明大家都被坑过。我拿一个特别经典的场景来演示完整的排查思路。现象你写了一个循环希望在遍历文件的同时统计每个文件的行数并把结果累加到一个变量里total0 for file in /tmp/data/*.txt; do count$(wc -l $file) total$((total count)) done echo 总行数: $total这段本身没问题。但如果你“优化”成下面这样就会掉进坑里total0 cat /tmp/data/*.txt | while read -r line; do total$((total 1)) done echo 总行数: $total # 输出还是0为什么total在循环外还是0因为管道后面的while是在**子Shellsubshell**中执行的子Shell里对变量的修改不会带回到父Shell。这是Shell里最经典的坑之一。排查链路是这样的先确认total在循环内是否有值在while里加一行echo $total发现值是递增的。再确认循环结束后是否还保留在循环后紧接着echo $total发现归零了。由此断定是子Shell作用域问题。解决方案有两种一种是把循环写成进程替换process substitutionwhile read -r line; do ... done (cat /tmp/data/*.txt)这样循环在当前Shell中执行另一种是把累加逻辑放在循环外面像前面那段用for加wc -l的写法。这个坑相当普遍尤其是做过Python、Go这类语言的人会默认循环里的变量在循环外仍然可见但Shell在这里的语义不同。遇到类似“循环里算好的值出来后不见了”的问题优先怀疑子Shell上下文。3.3 调试脚本set -x、bash -n和“打印大法”的正确用法很多人发现问题靠瞎猜问题是排查要有方法论。语法检查先行bash -n script.sh这个命令只做语法解析不执行。如果有语法错误它会直接报出来。经常写脚本的人每次改完代码先跑一遍bash -n等于编译器的“编译检查”。跟踪执行过程bash -x script.sh这个会把每一条执行的命令和展开后的结果打印到终端。这是排查脚本逻辑的最佳工具。比如你怀疑某个变量展开不对用-x执行后就能看到每次命令实际传入了什么值。也可以在脚本内部临时打开set -x # 这段执行会打印每条命令 set x不要舍不得打印中间变量。我见过太多人写脚本时把echo 正在处理...当成日志却不打印关键变量的值。实践中最有用的调试方法是在关键节点打印变量值尤其是在算数、字符串替换、路径拼接之后echo DEBUG: 处理文件 $file新路径是 ${dir}/${name}.jpg 2这里的2是把调试信息输出到标准错误这样即使脚本的stdout被重定向到文件这些信息也不会混入结果中。3.4 一个真实的批量改名脚本把前面的知识点串起来我直接给一个可以复用的模板完整体现我前面说的“加保护、做检查、可调试”的风格#!/usr/bin/env bash # # 批量把目录下指定扩展名的文件改为小写扩展名 # 用法: ./lower_ext.sh /data/images JPG # set -euo pipefail dir${1:?请指定目录} ext${2:?请指定扩展名如 JPG} count0 for file in $dir/*.$ext; do [ -e $file ] || continue newname${file%.$ext}.${ext,,} if [[ $file $newname ]]; then continue fi mv $file $newname echo 已重命名: $file - $newname count$((count 1)) done echo 完成共处理 $count 个文件。解读几个设计决策${file%.$ext}去掉文件名的原始扩展名${ext,,}把扩展名转成小写这是Bash 4.0支持的参数展开[ -e $file ] || continue处理“没匹配到文件”的情况${dir:?请指定目录}如果没传参数脚本直接报错退出不需要再写一行判断4. 面试场上的Shell高频考点与实战套路搜索热词里“shell面试题”和“shell脚本编程100例”的热度一直很高这说明Shell在技术面试里仍然是硬通货。作为写过不少脚本、也面试过别人的人我总结一下真正的考察重点。4.1 面试官真正关心的三个能力第一对文本处理命令的熟练度。grep、sed、awk这三兄弟基本是必考。考法通常是一个实际任务比如“从一个nginx日志里统计出现次数最多的IP前10名”。面试官想看的不是你会不会背参数而是能不能输出一条管道命令加排序和去重awk {print $1} access.log | sort | uniq -c | sort -rn | head -10这行命令拆开来看每个命令都不难但组合起来的时间复杂度和可读性就是分水岭。sort和uniq -c配合能统计重复行的次数再按次数倒序排取前10这个套路几乎每个运维和后台开发都应该形成肌肉记忆。第二对退出码和错误处理的理解。比如这道高频题“怎么实现一个失败的命令不会终止脚本”答案就是set e或者command || true以及if command; then ... fi的写法。又或者“有一段命令可能失败但你又希望它即使失败也继续运行后续步骤”这种场景在实际脚本里太常见了。理解了set -e的“一旦失败立即退出”机制才能理解为什么有时要在特定命令后面手动加上|| true。第三对脚本性能的敏感性。很多人写循环用cat逐行读在大文件上慢得离谱。一个经典的优化是把循环里的多次管道调用改成一次awk处理。比如你要遍历文件里的每一行做字符串截取用Shell for循环加awk跑10万行可能要几秒甚至更久但直接一条awk命令性能提升不是一个量级的。4.2 综合案例从需求到脚本的完整推演这里我设计一个常见的综合场景写一个脚本监控某个端口是否监听正常异常时输出诊断信息。这个需求综合了循环、条件、命令替换、函数、调试等多个知识点#!/usr/bin/env bash # # 端口监控脚本检查端口是否在监听异常时输出诊断信息 # 用法: ./port_check.sh [端口号] # set -euo pipefail PORT${1:?请指定端口号如 8080} check_port() { local port$1 if ss -tlnp | grep -q :$port ; then return 0 else return 1 fi } if check_port $PORT; then echo [OK] 端口 $PORT 正在监听。 else echo [WARN] 端口 $PORT 未监听开始诊断... # 检查进程是否存在 pgrep -f java.*server /dev/null echo 有Java进程存在 || echo 没有找到相关Java进程 # 检查iptables规则 iptables -L -n | grep $PORT /dev/null echo 防火墙有放行规则 || echo 防火墙没有放行该端口 # 尝试用nc连接本机端口 timeout 2 bash -c echo /dev/tcp/127.0.0.1/$PORT /dev/null 21 \ echo 本机连接测试正常 \ || echo 本机连接测试失败 fi这里有几个容易被忽略的细节。ss -tlnp | grep -q :$port 注意grep匹配模式里端口后面有个空格是为了避免8080匹配到18080这类包含关系。grep -q只判断匹配与否不输出内容配合if条件判断非常干净利落。timeout 2 bash -c echo /dev/tcp/127.0.0.1/$PORT/dev/tcp/是Bash内置的虚拟路径向这个路径做重定向就相当于建立TCP连接。timeout命令防止连接挂住导致整个脚本卡死。4.3 如何用“一百例”的方式练习而不是刷题很多人问怎么提升Shell水平网上也确实有“shell脚本编程100例”这种资源。我的看法是单纯把100个例子看一遍价值不高重要的是怎么练习。我推荐的方法是把每个例子当成“三遍练习”来做第一遍照着抄一遍确保能跑通。第二遍不看答案凭记忆重写。这一步你会痛苦地发现很多细节忘了比如括号语法、引号位置。忘了就翻回去对比标记自己容易错的地方。第三遍改需求自己扩展。比如原题是“统计日志中错误数量”你可以改成“统计超过特定阈值的IP并输出到文件”。这个改动会迫使你调用前面学过的循环、条件、重定向知识。不必贪多一周吃透三五个例子坚持一个月比一次性刷100个效果要好太多。5. 围绕Shell常见运维和故障场景的深层避坑清单虽然统一叫第三部曲里的内容但日常使用Shell时分布着不少零散、隐蔽的问题。我最后再整理一份真正高频踩坑的清单每个都带具体的表现和解法。5.1 文件名里的空格、换行、特殊字符为什么总是会炸这是一个老生常谈但反复出现的坑。Shell脚本没处理好文件名轻则处理漏掉重则把文件删错。常见错误是for file in $(find . -name *.txt); do rm $file done当find输出包含空格的文件名时for循环会把它拆成多个词结果rm拿到一堆不完整的路径。正确的做法就是用我前面讲过的-print0配合read -d 或者用find -exec直接处理find . -name *.txt -exec rm {} \;如果必须在脚本里同时处理复杂文件名和统计计数find -print0配合while是最灵活的。5.2 set -e和“短路的if逻辑”的冲突很多人开了set -e之后在if条件里写命令却发现行为不对劲。实际上if条件里的命令即使失败也不会触发-e退出——这正是if语义的核心。但在使用和||组合时就要小心了。比如set -e false echo 不会执行 echo 但这一行也不会执行为什么echo 但这一行也不会执行不执行因为false echo这个列表整体返回非零状态于是set -e触发了退出。这其实是一个很隐蔽的坑。很多人写“A B”时只想让B在A失败时跳过却无意中让整个脚本退出了。解决方法是如果希望这样的命令不触发退出可以把它包在if里if false echo 不会执行; then : fi echo 这行会正常执行5.3 中文环境和locale对命令输出的影响在运维脚本里有时需要解析命令输出来判断状态。例如grep listening来检查服务监听状态但有的系统locale是中文ss或netstat输出的可能是监听而不是listening。为了避免这种与语言环境相关的陷阱可以在脚本开头强制设置locale为C/POSIXexport LC_ALLC这样就能保证所有命令的输出格式是英文脚本解析可预测。这个细节在线上环境排查时非常实用尤其是你的脚本可能在被部署到不同语言环境的服务器上时。5.4 处理“孤儿进程”和不清理临时文件脚本执行到一半因为某个错误退出可能留下临时文件、后台进程甚至占用端口的进程。我建议在脚本开头就注册一个trap以保证脚本退出时做清理#!/usr/bin/env bash tmpfile/tmp/$(basename $0).$$.tmp cleanup() { rm -f $tmpfile } trap cleanup EXITtrap cleanup EXIT保证不管脚本是正常结束还是因为错误退出都会执行cleanup。这个习惯我在写稍微复杂一点的脚本时一定会用避免多次运行同一脚本时残留垃圾文件。5.5 Bash版本差异为什么脚本在macOS上挂了很多脚本写的时候在Linux上跑得好好的拿到macOS上一跑就报错。最典型的原因就是macOS默认使用的是3.2版本的Bash而现代Linux发行版都已经是5.x。前面提到的${var,,}转小写、[[ ]]的某些高级特性、mapfile这些功能在Bash 3.2上不是missing就是行为不一致。解决策略很简单脚本第一行用#!/usr/bin/env bash而不是#!/bin/bash然后在脚本最前面加个版本判断if ((BASH_VERSINFO[0] 4)); then echo 需要Bash 4.0以上版本 2 exit 1 fi另外如果只是想做简单文本处理更轻量的方案是直接考虑用awk或sed避免依赖Bash特有的高级特性。6. 一条从入门到独立写脚本的个人进阶路径行文到这里三部曲的主体内容已经讲完。我最后从一个偏实践的角度聊聊学Shell到底应该怎么规划路线。这个路线我自己实践过也推荐过不少同行算是踩过坑之后总结出来的。6.1 阶段一死磕基础命令和文本处理先能做到不用help和搜索就能写完一个包含grep、sed、awk、find、xargs组合的管道命令。这里有一个很实用的自测方法给你一个nginx日志文件你能不能在5分钟内统计出Top 10的请求IP、时间段分布、404状态码占比。这些能做到第一阶段就过关了。6.2 阶段二脚本结构化开始用函数、变量、循环、条件来组织脚本。这个阶段的目标是你的脚本不再是从上到下的一条直线而是有分支、有函数、有错误处理的结构体。每周找一个小需求写成脚本比如自动整理下载目录、按日期归档日志比反复看教程有效得多。6.3 阶段三健壮性与排查能力学会处理异常场景——参数缺失、文件不存在、权限不足、命令失败。学会用set -euo pipefail作为默认配置学会用bash -x调试学会用trap做清理。到了这个阶段你已经不会因为脚本在别的机器上跑不起来而慌了因为所有依赖环境和异常路径都已经在代码里做了明确的处理和提示。6.4 一个值得养成的习惯把脚本当代码来维护既然叫脚本“编程”就不要只把它当一次性命令。我自己的习惯是每个脚本都得有用途说明和用法注释变量命名要清晰少用a、b、tmp这种不明所以的名字关键算法处写注释解释为什么这么写提交到Git仓库做版本管理哪怕是一个只有20行的运维脚本加上set -euo pipefail、参数校验和基本的注释它的可靠性和可维护性都比随手写的命令高出几个档次。这个习惯一旦养成回头再看那些“能跑就行”的脚本你会不自觉地点点头哦原来当年踩过的坑都是因为少了这些基本功。Shell编程这东西入门不算难真正拉开差距的其实是细节——引号加没加、set -e开没开、有没有做参数校验、遇到异常会不会留下清晰日志。三部曲的脉络本质上是先把变量和参数玩明白再把流程控制和函数整理清楚最后在真实场景里打磨出对坑和边界的敏感度。到了那个阶段Shell对你来说就不再是“写命令”而是真正用来解决问题的工具。
Shell脚本编程三部曲：从变量参数到文件操作与调试避坑指南
Shell这三字看着简单但不少人在真正上手写脚本的时候卡在了同一个地方单个命令都会组合起来就懵。更别提参数处理、循环分支、异常排查这些东西零散学过一点真到写一个能用的脚本时还是不知道怎么搭骨架。这次借这组Shell三部曲我按自己的实操习惯把从入门到能独立写脚本的全过程重新梳理了一遍不堆概念直接讲清楚每一部里必须掌握的核心逻辑和常见坑希望能帮你少走点弯路。1. 第一部曲变量、参数与解析——先把地基打牢这一部解决的是脚本的“骨架”问题。很多人写脚本是从“命令行能跑”直接跳到“写个文件执行”中间漏掉了一整块内容——脚本和命令行的本质区别在于脚本需要你把输入、输出、参数这三样东西理清楚。1.1 从第一行到“能跑”中间隔着的不是命令是执行方式我知道很多人的第一个脚本长这样echo hello world然后在终端里执行bash test.sh看到输出就觉得“会写脚本了”。这没错但离真正的“脚本思维”还差一层。我建议你把脚本当成一个独立的程序来看待而不是“一堆命令的堆叠”。一个规范的脚本开头应该包含这几样东西#!/usr/bin/env bash # # 脚本用途描述 # 作者、日期、版本 # set -euo pipefail其中shebang#!那行指定了解释器set -euo pipefail这段值得单独讲讲因为它几乎是我见过最实用的一组脚本保护开关-e脚本中任何一条命令返回非零状态码时立即退出避免“前面失败了后面还在继续跑”的雪崩式问题。-u使用未定义的变量直接报错退出这个对排查拼写错误极其有效。-o pipefail管道中任何一个命令失败整个管道的返回状态就是失败的否则管道只认最后一个命令的状态。我用一个真实的例子说明一下为什么这三样组合起来非常重要。假设你写了一条这样的命令cat /tmp/data.txt | grep error | wc -l如果/tmp/data.txt不存在cat已经失败了但grep还是会执行wc -l还是会输出一个数字。你看到屏幕上有个0以为是“没有匹配到error”其实是“文件根本没读到”。开了pipefail之后这条命令会直接报错退出你才知道问题出在哪。类似的坑配合set -u能拦截掉很多变量名写错的情况比如$flie这种拼写错误没开-u的话它只是安静地展开成一个空字符串后续逻辑全错还很难查。1.2 变量展开的隐藏细节引号、特殊参数和常见误用写Shell脚本变量展开是绕不开的核心。这里想重点聊几个高频出问题的点。变量与引号namehello world echo $name # 输出 hello world但分词word splitting已经发生了 echo $name # 输出 hello world作为一个整体如果name的值是带空格的路径比如/data/my files/不加引号就可能被拆成两个参数。我在实际工作中见过太多因为没加引号导致的线上问题所以有一个习惯性的建议在绝大多数场景下变量展开都加上双引号除非你明确需要分词比如for i in $list这种刻意为之的场景。位置参数和特殊变量特殊变量含义实际用途$0脚本本身的文件名写日志或帮助信息时用$#传入参数的数量校验至少需要几个参数$所有参数每个都作为独立个体遍历参数时用$*所有参数合并成一个字符串想整体传递所有参数时用$?上一条命令的退出码判断命令是否成功$$当前进程的PID生成临时文件名时防冲突这里最容易犯错的是$和$*的区别。直接看这个例子#!/usr/bin/env bash print_args() { for arg in $; do echo 参数: $arg done } print_args hello world second用$时输出两行分别是hello world和second。但如果把$换成$*只会输出一行hello world second。很多人在写“遍历所有参数”的脚本时用了$*结果带空格的参数全部被拆散调试半天才发现是引号和$/$*的差异导致的。还有$?的使用时机问题它只保留上一条命令的状态一旦你执行了其他命令旧的状态就被覆盖了。所以如果需要保存某个命令的退出状态第一时间存进变量if grep -q pattern file.txt; then status$? echo 状态已保存: $status fi1.3 命令替换与算术展开不是“能算数”就行Shell脚本里经常需要把命令的输出赋给变量这就是命令替换today$(date %Y-%m-%d) file_count$(ls /tmp | wc -l)注意这里用的是$(...)我建议完全不用剥引号包裹的反引号...风格因为反引号在处理嵌套和转义时非常痛苦$(...)可以嵌套使用可读性好得多。算术运算也是一样$((...))是标准写法里面的变量名可以不加$前缀i1 next$((i 1)) echo $next很多初学者会用expr或者更糟用let但在现代Shell里$((...))才是简洁且不易出错的方式。如果需要浮点数计算那就要用bc或awk了但那是另一个话题。2. 第二部曲循环、分支与函数——让脚本长出四肢骨架有了接下来是四肢。这一部是脚本从“单行道”变成“立交桥”的关键。搜索热词里有不少“shell脚本for循环”“shell的shift命令”相关的查询可见大家对这些控制流的理解还停留在“看过没写过”的程度。2.1 for循环最被低估的一种遍历方式for循环看起来人尽皆知但真到实战里很多人只会一种写法for i in 1 2 3 4 5; do echo $i done但这个写法只是for的冰山一角。实际工作中更常用的几种形态遍历文件列表for file in /var/log/*.log; do echo 处理: $file done这里有一个非常值得注意的坑当目录下没有匹配的.log文件时/var/log/*.log不会被展开而是作为一个字面字符串传给循环。这意味着$file会变成/var/log/*.log这个不存在的路径。所以安全写法是加上一个判断for file in /var/log/*.log; do [ -e $file ] || continue echo 处理: $file doneC风格循环精确控制次数for ((i 0; i 10; i)); do echo 第 $i 次 done这个特别适合处理数字逻辑比seq命令生成列表再遍历要快也更清晰。遍历带空格的文件名最优雅的方案是利用find配合while循环而不是forfind /data -name *.txt -print0 | while IFS read -r -d line; do echo 文件: $line done-print0和-d 配套使用用空字符而不是换行来分隔文件名这样文件名再奇葩包含空格、换行也不会出错。这里IFS是防止read把行首尾的空格吃掉-r防止反斜杠被转义解释。这套组合建议直接记下来。2.2 条件判断test、[]和[[ ]]的差别真不是玄学条件判断是脚本逻辑的分流阀。你可能见过if [ $a b ]也见过if [[ $a b ]]但未必清楚它们之间的关系。[ ]其实是test命令的语法糖衣[是一个独立的可执行文件不信可以在终端里输入type -a [看看。所以[里的变量需要加引号否则空变量或带空格的变量会让表达式出错。[[ ]]则是Shell内置的关键字不是外部命令。它的优势是支持和||逻辑运算而[ ]里只能写-a和-o不够直观且已不推荐支持正则匹配~变量即使不带引号也不会因为空格而拆词支持模式匹配在[[ ]]里右侧可以包含通配符做个对比strhello world if [ $str hello ]; then # 会报错参数太多 ... fi if [ $str hello ]; then # 正确但写法繁琐 ... fi if [[ $str *world* ]]; then # 支持通配符匹配非常方便 ... fi我现在写脚本的条件判断几乎一律用[[ ]]只有在必须兼容POSIX sh比如某些嵌入式环境里只有/bin/sh时才用[ ]。2.3 函数与返回值别用echo传结果Shell函数和大多数语言里函数的“返回”概念不太一样。Shell函数的返回值是退出状态码0到255而不是任意数据。所以想从函数返回一个字符串通常有两种做法用echo输出调用方用$(函数名)捕获用全局变量第一种更通用但有个需要注意的地方函数里的日志输出和结果输出要分开。看这个反例get_ip() { echo 开始获取IP... # 这行日志不能出现在结果里 hostname -I | awk {print $1} } ip$(get_ip) echo IP is: $ip你得到的$ip不是IP而是开始获取IP...和IP拼在一起的字符串。所以一个有经验的写法是把日志输出到标准错误stderrget_ip() { echo 开始获取IP... 2 hostname -I | awk {print $1} }调用方拿到的stdout就是干净的结果日志也还能看到。函数定义方面可以在函数体内用local声明局部变量这能大大降低函数之间的变量名冲突问题process_file() { local filename$1 local tmpfile tmpfile/tmp/$(basename $filename).$$.tmp # 这里即使有变量叫 filename也不会影响全局的同名变量 }2.4 shift命令参数解析的隐藏利器搜索热词里出现了“shell的shift命令”这确实是很多人忽略但实战价值很高的命令。shift的作用是把位置参数左移$2变成$1$3变成$2同时$#减一。配合while循环可以优雅地解析带选项的命令行参数。举个例子你希望脚本支持这种调用方式./script.sh -f config.ini -v --output out.txt用shift可以这样写#!/usr/bin/env bash verbose0 config output while [ $# -gt 0 ]; do case $1 in -f) config$2 shift 2 ;; -v) verbose1 shift ;; --output) output$2 shift 2 ;; *) echo 未知参数: $1 2 exit 1 ;; esac done echo config$config, verbose$verbose, output$output这种方式比手工一个参数一个参数去判断清晰得多而且扩展起来非常方便。shift 2表示左移两个位置这样$1就指向了下一个选项。注意shift数字不能超过$#否则Shell会报语法错误——所以while [ $# -gt 0 ]这个条件实际上是保护也是循环正常终止的关键。另外有个细节shift本身也会返回状态码就算你写成shift 5而只剩3个参数它不会报错只是会把所有参数都移完并把$#变成0。实测中更安全的做法是通过$#判断后再shift。3. 第三部曲文件操作与调试——脚本落地时真正的拦路虎前面两部分把语法和逻辑讲得差不多了但脚本“写出来”和“能安全地用起来”之间还有一段路要趟。这一段我拿搜索热词里出现频率很高的“linux用shell重命名文件”和“shell中常见坑”来展开这些都是真实场景中最容易翻车的地方。3.1 批量重命名一个mv命令藏了多少细节很多人看到“重命名文件”第一反应就是mv old new这是对的。但批量重命名才是实战里的高频需求比如把目录下所有*.JPG改成*.jpg、把report_2025.txt改成report_2026.txt。最基本的改名就是mv加引号mv report 2025.txt report 2026.txt但批量的时候新手最容易踩的坑是直接把for循环里的变量拼到新文件名中却忘了处理扩展名和路径前缀。下面这段代码就是一个经典的反面教材# 错误示范默认当前目录却忘记去掉路径前缀 for file in /data/images/*.JPG; do mv $file $(basename $file .JPG).jpg done咦这里只改了后缀看起来没问题其实有一个非常隐蔽的细节$(basename $file .JPG).jpg编辑后只剩文件名没有目录前缀所以mv会把新文件生成到当前工作目录而不是/data/images/目录下。你需要的是for file in /data/images/*.JPG; do dir$(dirname $file) name$(basename $file .JPG) mv $file $dir/$name.jpg done这个坑我踩过不止一次因为mv跨目录移动时目标路径没有目录前缀导致文件全部散落到当前目录后面还得手动搬回去。如果是更复杂的重命名规则比如替换文件名中的特定字符串可以用Shell的参数扩展newname${file/old/new}这行命令把$file中第一个匹配old的部分替换为new。配合批量循环比用sed再拼接要快。3.2 常见坑的完整排查链路以“for循环里管道失效”为例搜索热词里有“shell中常见坑”这是个好信号说明大家都被坑过。我拿一个特别经典的场景来演示完整的排查思路。现象你写了一个循环希望在遍历文件的同时统计每个文件的行数并把结果累加到一个变量里total0 for file in /tmp/data/*.txt; do count$(wc -l $file) total$((total count)) done echo 总行数: $total这段本身没问题。但如果你“优化”成下面这样就会掉进坑里total0 cat /tmp/data/*.txt | while read -r line; do total$((total 1)) done echo 总行数: $total # 输出还是0为什么total在循环外还是0因为管道后面的while是在**子Shellsubshell**中执行的子Shell里对变量的修改不会带回到父Shell。这是Shell里最经典的坑之一。排查链路是这样的先确认total在循环内是否有值在while里加一行echo $total发现值是递增的。再确认循环结束后是否还保留在循环后紧接着echo $total发现归零了。由此断定是子Shell作用域问题。解决方案有两种一种是把循环写成进程替换process substitutionwhile read -r line; do ... done (cat /tmp/data/*.txt)这样循环在当前Shell中执行另一种是把累加逻辑放在循环外面像前面那段用for加wc -l的写法。这个坑相当普遍尤其是做过Python、Go这类语言的人会默认循环里的变量在循环外仍然可见但Shell在这里的语义不同。遇到类似“循环里算好的值出来后不见了”的问题优先怀疑子Shell上下文。3.3 调试脚本set -x、bash -n和“打印大法”的正确用法很多人发现问题靠瞎猜问题是排查要有方法论。语法检查先行bash -n script.sh这个命令只做语法解析不执行。如果有语法错误它会直接报出来。经常写脚本的人每次改完代码先跑一遍bash -n等于编译器的“编译检查”。跟踪执行过程bash -x script.sh这个会把每一条执行的命令和展开后的结果打印到终端。这是排查脚本逻辑的最佳工具。比如你怀疑某个变量展开不对用-x执行后就能看到每次命令实际传入了什么值。也可以在脚本内部临时打开set -x # 这段执行会打印每条命令 set x不要舍不得打印中间变量。我见过太多人写脚本时把echo 正在处理...当成日志却不打印关键变量的值。实践中最有用的调试方法是在关键节点打印变量值尤其是在算数、字符串替换、路径拼接之后echo DEBUG: 处理文件 $file新路径是 ${dir}/${name}.jpg 2这里的2是把调试信息输出到标准错误这样即使脚本的stdout被重定向到文件这些信息也不会混入结果中。3.4 一个真实的批量改名脚本把前面的知识点串起来我直接给一个可以复用的模板完整体现我前面说的“加保护、做检查、可调试”的风格#!/usr/bin/env bash # # 批量把目录下指定扩展名的文件改为小写扩展名 # 用法: ./lower_ext.sh /data/images JPG # set -euo pipefail dir${1:?请指定目录} ext${2:?请指定扩展名如 JPG} count0 for file in $dir/*.$ext; do [ -e $file ] || continue newname${file%.$ext}.${ext,,} if [[ $file $newname ]]; then continue fi mv $file $newname echo 已重命名: $file - $newname count$((count 1)) done echo 完成共处理 $count 个文件。解读几个设计决策${file%.$ext}去掉文件名的原始扩展名${ext,,}把扩展名转成小写这是Bash 4.0支持的参数展开[ -e $file ] || continue处理“没匹配到文件”的情况${dir:?请指定目录}如果没传参数脚本直接报错退出不需要再写一行判断4. 面试场上的Shell高频考点与实战套路搜索热词里“shell面试题”和“shell脚本编程100例”的热度一直很高这说明Shell在技术面试里仍然是硬通货。作为写过不少脚本、也面试过别人的人我总结一下真正的考察重点。4.1 面试官真正关心的三个能力第一对文本处理命令的熟练度。grep、sed、awk这三兄弟基本是必考。考法通常是一个实际任务比如“从一个nginx日志里统计出现次数最多的IP前10名”。面试官想看的不是你会不会背参数而是能不能输出一条管道命令加排序和去重awk {print $1} access.log | sort | uniq -c | sort -rn | head -10这行命令拆开来看每个命令都不难但组合起来的时间复杂度和可读性就是分水岭。sort和uniq -c配合能统计重复行的次数再按次数倒序排取前10这个套路几乎每个运维和后台开发都应该形成肌肉记忆。第二对退出码和错误处理的理解。比如这道高频题“怎么实现一个失败的命令不会终止脚本”答案就是set e或者command || true以及if command; then ... fi的写法。又或者“有一段命令可能失败但你又希望它即使失败也继续运行后续步骤”这种场景在实际脚本里太常见了。理解了set -e的“一旦失败立即退出”机制才能理解为什么有时要在特定命令后面手动加上|| true。第三对脚本性能的敏感性。很多人写循环用cat逐行读在大文件上慢得离谱。一个经典的优化是把循环里的多次管道调用改成一次awk处理。比如你要遍历文件里的每一行做字符串截取用Shell for循环加awk跑10万行可能要几秒甚至更久但直接一条awk命令性能提升不是一个量级的。4.2 综合案例从需求到脚本的完整推演这里我设计一个常见的综合场景写一个脚本监控某个端口是否监听正常异常时输出诊断信息。这个需求综合了循环、条件、命令替换、函数、调试等多个知识点#!/usr/bin/env bash # # 端口监控脚本检查端口是否在监听异常时输出诊断信息 # 用法: ./port_check.sh [端口号] # set -euo pipefail PORT${1:?请指定端口号如 8080} check_port() { local port$1 if ss -tlnp | grep -q :$port ; then return 0 else return 1 fi } if check_port $PORT; then echo [OK] 端口 $PORT 正在监听。 else echo [WARN] 端口 $PORT 未监听开始诊断... # 检查进程是否存在 pgrep -f java.*server /dev/null echo 有Java进程存在 || echo 没有找到相关Java进程 # 检查iptables规则 iptables -L -n | grep $PORT /dev/null echo 防火墙有放行规则 || echo 防火墙没有放行该端口 # 尝试用nc连接本机端口 timeout 2 bash -c echo /dev/tcp/127.0.0.1/$PORT /dev/null 21 \ echo 本机连接测试正常 \ || echo 本机连接测试失败 fi这里有几个容易被忽略的细节。ss -tlnp | grep -q :$port 注意grep匹配模式里端口后面有个空格是为了避免8080匹配到18080这类包含关系。grep -q只判断匹配与否不输出内容配合if条件判断非常干净利落。timeout 2 bash -c echo /dev/tcp/127.0.0.1/$PORT/dev/tcp/是Bash内置的虚拟路径向这个路径做重定向就相当于建立TCP连接。timeout命令防止连接挂住导致整个脚本卡死。4.3 如何用“一百例”的方式练习而不是刷题很多人问怎么提升Shell水平网上也确实有“shell脚本编程100例”这种资源。我的看法是单纯把100个例子看一遍价值不高重要的是怎么练习。我推荐的方法是把每个例子当成“三遍练习”来做第一遍照着抄一遍确保能跑通。第二遍不看答案凭记忆重写。这一步你会痛苦地发现很多细节忘了比如括号语法、引号位置。忘了就翻回去对比标记自己容易错的地方。第三遍改需求自己扩展。比如原题是“统计日志中错误数量”你可以改成“统计超过特定阈值的IP并输出到文件”。这个改动会迫使你调用前面学过的循环、条件、重定向知识。不必贪多一周吃透三五个例子坚持一个月比一次性刷100个效果要好太多。5. 围绕Shell常见运维和故障场景的深层避坑清单虽然统一叫第三部曲里的内容但日常使用Shell时分布着不少零散、隐蔽的问题。我最后再整理一份真正高频踩坑的清单每个都带具体的表现和解法。5.1 文件名里的空格、换行、特殊字符为什么总是会炸这是一个老生常谈但反复出现的坑。Shell脚本没处理好文件名轻则处理漏掉重则把文件删错。常见错误是for file in $(find . -name *.txt); do rm $file done当find输出包含空格的文件名时for循环会把它拆成多个词结果rm拿到一堆不完整的路径。正确的做法就是用我前面讲过的-print0配合read -d 或者用find -exec直接处理find . -name *.txt -exec rm {} \;如果必须在脚本里同时处理复杂文件名和统计计数find -print0配合while是最灵活的。5.2 set -e和“短路的if逻辑”的冲突很多人开了set -e之后在if条件里写命令却发现行为不对劲。实际上if条件里的命令即使失败也不会触发-e退出——这正是if语义的核心。但在使用和||组合时就要小心了。比如set -e false echo 不会执行 echo 但这一行也不会执行为什么echo 但这一行也不会执行不执行因为false echo这个列表整体返回非零状态于是set -e触发了退出。这其实是一个很隐蔽的坑。很多人写“A B”时只想让B在A失败时跳过却无意中让整个脚本退出了。解决方法是如果希望这样的命令不触发退出可以把它包在if里if false echo 不会执行; then : fi echo 这行会正常执行5.3 中文环境和locale对命令输出的影响在运维脚本里有时需要解析命令输出来判断状态。例如grep listening来检查服务监听状态但有的系统locale是中文ss或netstat输出的可能是监听而不是listening。为了避免这种与语言环境相关的陷阱可以在脚本开头强制设置locale为C/POSIXexport LC_ALLC这样就能保证所有命令的输出格式是英文脚本解析可预测。这个细节在线上环境排查时非常实用尤其是你的脚本可能在被部署到不同语言环境的服务器上时。5.4 处理“孤儿进程”和不清理临时文件脚本执行到一半因为某个错误退出可能留下临时文件、后台进程甚至占用端口的进程。我建议在脚本开头就注册一个trap以保证脚本退出时做清理#!/usr/bin/env bash tmpfile/tmp/$(basename $0).$$.tmp cleanup() { rm -f $tmpfile } trap cleanup EXITtrap cleanup EXIT保证不管脚本是正常结束还是因为错误退出都会执行cleanup。这个习惯我在写稍微复杂一点的脚本时一定会用避免多次运行同一脚本时残留垃圾文件。5.5 Bash版本差异为什么脚本在macOS上挂了很多脚本写的时候在Linux上跑得好好的拿到macOS上一跑就报错。最典型的原因就是macOS默认使用的是3.2版本的Bash而现代Linux发行版都已经是5.x。前面提到的${var,,}转小写、[[ ]]的某些高级特性、mapfile这些功能在Bash 3.2上不是missing就是行为不一致。解决策略很简单脚本第一行用#!/usr/bin/env bash而不是#!/bin/bash然后在脚本最前面加个版本判断if ((BASH_VERSINFO[0] 4)); then echo 需要Bash 4.0以上版本 2 exit 1 fi另外如果只是想做简单文本处理更轻量的方案是直接考虑用awk或sed避免依赖Bash特有的高级特性。6. 一条从入门到独立写脚本的个人进阶路径行文到这里三部曲的主体内容已经讲完。我最后从一个偏实践的角度聊聊学Shell到底应该怎么规划路线。这个路线我自己实践过也推荐过不少同行算是踩过坑之后总结出来的。6.1 阶段一死磕基础命令和文本处理先能做到不用help和搜索就能写完一个包含grep、sed、awk、find、xargs组合的管道命令。这里有一个很实用的自测方法给你一个nginx日志文件你能不能在5分钟内统计出Top 10的请求IP、时间段分布、404状态码占比。这些能做到第一阶段就过关了。6.2 阶段二脚本结构化开始用函数、变量、循环、条件来组织脚本。这个阶段的目标是你的脚本不再是从上到下的一条直线而是有分支、有函数、有错误处理的结构体。每周找一个小需求写成脚本比如自动整理下载目录、按日期归档日志比反复看教程有效得多。6.3 阶段三健壮性与排查能力学会处理异常场景——参数缺失、文件不存在、权限不足、命令失败。学会用set -euo pipefail作为默认配置学会用bash -x调试学会用trap做清理。到了这个阶段你已经不会因为脚本在别的机器上跑不起来而慌了因为所有依赖环境和异常路径都已经在代码里做了明确的处理和提示。6.4 一个值得养成的习惯把脚本当代码来维护既然叫脚本“编程”就不要只把它当一次性命令。我自己的习惯是每个脚本都得有用途说明和用法注释变量命名要清晰少用a、b、tmp这种不明所以的名字关键算法处写注释解释为什么这么写提交到Git仓库做版本管理哪怕是一个只有20行的运维脚本加上set -euo pipefail、参数校验和基本的注释它的可靠性和可维护性都比随手写的命令高出几个档次。这个习惯一旦养成回头再看那些“能跑就行”的脚本你会不自觉地点点头哦原来当年踩过的坑都是因为少了这些基本功。Shell编程这东西入门不算难真正拉开差距的其实是细节——引号加没加、set -e开没开、有没有做参数校验、遇到异常会不会留下清晰日志。三部曲的脉络本质上是先把变量和参数玩明白再把流程控制和函数整理清楚最后在真实场景里打磨出对坑和边界的敏感度。到了那个阶段Shell对你来说就不再是“写命令”而是真正用来解决问题的工具。 
