这段时间在做Shell脚本的第二次作业痛苦程度比第一次翻了不止一倍。第一次作业基本就是照着PPT敲几个echo和cd交上去就算完事第二次作业开始真正要求用脚本解决实际问题——处理参数、循环文件、过滤文本还得考虑脚本跑挂了怎么排查。说实话我在这个过程中踩了不少坑有些坑网上资料写得含糊有些坑纯粹是自己想当然。这篇东西就把我从拿到题目到提交作业的全过程记录下来包括题目分析、脚本思路、踩坑经历和调试方法给正在做类似作业或者刚入门Shell脚本的朋友做个参考。1. 第二次作业的题目长什么样从会敲命令到会写脚本的坎1.1 我拿到的题目要求作业题目的大意是写一个Shell脚本实现文件批量整理功能。具体要求有五个方向对指定目录下的文件按扩展名归类并统计数量批量重命名包含特定关键字的文件脚本要支持-d、-h等命令行参数输出结果时能用颜色区分警告和信息目录不存在或参数错误时脚本要给出友好提示而不是直接抛出一堆报错然后崩溃。题目还额外要求脚本里的关键函数必须有注释整个脚本要能重复执行不产生副作用。说白了就是要把一堆日常手动执行的命令串起来让脚本替你做并且做得比人更稳。1.2 为什么这类题对新手这么难因为之前的练习都是单条命令执行现在突然要你有脚本思维。初学Shell的人通常会卡在两种状态一种是只会在命令行敲命令把命令堆到一个文件里发现跑不通另一种是看得懂每条命令但组合起来完全不知道从哪下手。我第一次翻车就翻在这手动执行mv a.txt b.txt没问题写进脚本加个循环就开始各种报错。要么是变量没展开要么是IFS把带空格的文件名拆碎了要么是通配符在引号里失效。等我把这些坑一个个踩平才意识到第二次作业考察的根本不是会不会用某条命令而是能不能把命令当成积木搭出一个逻辑自洽的系统。这个认知转变很重要。如果你也正在做类似的第二次作业我建议先别急着写代码拿张纸把脚本的执行流程画出来接收什么参数、判断什么条件、循环哪些文件、输出什么格式。流程清晰了代码只是翻译工作。2. 变量、输入与for循环Shell脚本的地基三件套2.1 变量展开规则单引号、双引号和不加引号第二次作业里80%的脚本运行异常都出在变量展开上。echo $var、echo $var、echo $var三种写法行为完全不同这个知识点如果只停在知道层面很快就会被现实教育。看一个最常见的例子dir/tmp/my files mkdir $dir这条命令执行后mkdir实际收到的是两个参数/tmp/my和files。目录不存在时你会看到两条报错mkdir: cannot create directory /tmp/my: No such file or directory和mkdir: cannot create directory files: No such file or directory。很多人第一次看到这种报错完全懵了明明路径没问题啊。改成都双引号包住就好了dir/tmp/my files mkdir $dir单引号、双引号和不加引号的区别可以简单理解为单引号里的内容全部原样输出$符号不解析双引号里的$符号照样解析变量但空格、通配符这类特殊字符会被当成普通字符不加引号则Shell会做词拆分和通配符展开。在脚本里处理带空格的文件名时必须用双引号包裹这是批量重命名场景里最关键的一条规则。2.2 read输入脚本与用户交互的桥梁作业里有一个环节是让用户输入目标目录路径。这里用read命令来实现交互read -p 请输入要整理的目录路径: target_dir-p用于显示提示文本输入的内容会存入变量target_dir。read的几个常用参数值得记一下-r表示不把反斜杠当作转义字符读取文件路径时建议加上-t设定超时秒数用户在指定时间内不输入就继续往下走-s隐藏输入内容适合输入密码场景。我在作业里给read加了超时和默认值处理这样用户直接回车也能继续执行read -rt 10 -p 请输入目录路径(10秒内回车使用默认值/tmp/input): target_dir target_dir${target_dir:-/tmp/input}2.3 for循环的三种常见写法题目里的批量重命名和统计功能都离不开循环。for循环的写法有好几种我整理了一下实际用到的# 写法一遍历当前目录下的所有txt文件 for file in *.txt; do echo $file done # 写法二C风格循环适合数字范围 for ((i1; i10; i)); do echo $i done # 写法三结合seq命令 for i in $(seq 1 10); do echo $i done这里必须提醒一个新手极其容易踩的坑不要用for file in $(ls *.txt)这种写法。因为命令替换的结果会被Shell做词拆分一旦文件名带空格循环变量file拿到的就不是完整文件名而是被拆碎后的片段。正确的做法是直接用通配符*.txtShell会把匹配到的文件名作为整体交给循环处理。如果需要按行读取文件内容用while read而不是forwhile IFS read -r line; do echo 处理: $line done $input_fileIFS清空了默认的分隔符-r防止反斜杠转义这样每一行都能被原样读到不会因为行里有空格或者特殊字符而出错。这个写法在处理日志文件时几乎是标配。3. 文本过滤与统计grep在脚本里的正确用法3.1 grep常用参数速查题目里有一个子任务是统计日志中ERROR出现的次数grep是绕不开的工具。我整理的常用参数是这些参数作用脚本里的使用场景-c输出匹配行数统计某个模式出现次数-E使用扩展正则匹配多个关键字-v反向匹配排除掉特定内容-r递归搜索遍历目录下所有文件-q静默模式不输出内容只关心是否有匹配-h匹配结果不显示文件名多文件统计时去掉前缀3.2 把grep放进条件判断里grep在脚本里最容易被忽略的一点是它的退出码。匹配到内容时返回0没匹配到时返回1出错时返回2。这个特性让它可以直接作为if条件if grep -q ERROR app.log; then echo 发现错误 fi注意这里的-q参数。如果不加grep会把匹配到的内容打印到标准输出脚本执行时屏幕上会冒出大量无关信息而且数据量大时还会拖慢速度。加上-q之后grep不再输出内容只保留退出码的含义。3.3 多文件统计的完整场景作业里要求统计一个目录下所有.log文件中的ERROR数量。我最开始写的是这种一把梭的写法total$(cat *.log | grep -c ERROR)看起来简洁实际上坑很多。第一cat *.log把所有文件内容合并后再过滤一旦文件数量多内存占用会很难看第二如果某个文件里没有匹配内容grep -c会输出文件名加0而不是我们期望的纯数字最终total变量里混进了奇怪的内容第三某个文件为空时cat会直接报错。后来我改成逐文件循环累加total0 for file in *.log; do count$(grep -hc ERROR $file) # 当文件无匹配时grep -c 输出0没问题 total$((total count)) done echo ERROR总数: $totalgrep -h的作用是去掉文件名前缀保证count拿到的是纯数字。这里我还额外做了个判断如果count不是纯数字比如grep报错输出了错误信息就强制置为0避免算术表达式求值失败。这种防御性写法在Shell脚本里特别重要。4. 位置参数、shift与后台执行的三重考验4.1 位置参数解析$1、$2、$#与shift题目要求解析-d和-h参数这就离不开位置参数。$0是脚本名$1、$2依次是第一个、第二个位置参数$#是参数个数$和$*都能拿到全部参数区别在于$把每个参数当成独立的个体$*把所有参数拼成一个字符串。shift命令负责把位置参数整体左移原来的$2变成新的$1。持续调用shift就能逐个消费参数。我写的参数解析循环是这样的dir while [ $# -gt 0 ]; do case $1 in -d) dir$2 shift 2 ;; -h) usage exit 0 ;; *) echo 未知参数: $1 exit 1 ;; esac done关键点在于-d分支要写shift 2而不是shift因为-d后面还要跟一个目录路径值必须把两个位置都移走。如果只写shift下一次循环拿到的$1就会是-d后面的那个路径case匹配不到直接走了*分支报错退出。这里还有个小坑case里匹配到未知参数时一定要exit不能只是echo提示一下然后继续循环。否则参数一直没被消费会陷入无限循环脚本瞬间满屏刷报错。4.2 脚本放到后台执行还要交互输密码的坑这个坑是我做作业时踩得最深的一次。当时脚本里有一段需要用户输入密码的场景我为了图省事直接写read -s -p 请输入密码: pwd。单条命令测试时一切正常。等我把脚本整合完用后台方式跑到真实数据上时出事了./organize.sh output.log 21 脚本在read那一步彻底卡死日志里没有任何提示进程一直挂在那好像整个世界都停了一样。我一开始以为是数据量大处理慢等了几分钟才反应过来不对。原因是后台进程的标准输入已经不指向终端了。read从标准输入读数据时发现没有可读内容直接读了EOF拿到一个空字符串然后校验失败、提示错误、再读、又EOF。有些实现甚至会让进程一直等待表现为卡死不退出。这个问题的解法有三条路把交互式输入前置到脚本启动之前用参数或环境变量传入敏感信息避免脚本运行到中途再要输入。不要整个脚本后台执行只把耗时的处理函数放后台交互部分留在前台。用expect这类工具模拟交互式输入但我个人觉得为了一个密码专门引入expect有点重。我最终采用的方案是脚本支持通过环境变量传入密码没设置环境变量时才走交互式read。这样既保留了灵活性又不会出现后台执行卡死的情况。4.3 Shell脚本中的其他常见坑我把这次作业和以前遇到的坑汇总成了一张表每一条都是实际发生过的坑现象原因解决方法脚本第一行不是#!/bin/bash行为诡异语法支持不一致解释器选错写脚本必加shebang文件是Windows换行符报错$\r: command not found换行符多了\rdos2unix转格式没加执行权限提示Permission denied文件不可执行chmod x script.sh循环里的变量值神秘消失变量看起来是对的但输出为空$file没加双引号被词拆分统一加双引号cd命令失败还继续跑后续操作全在错误目录执行cd找不到目录但脚本没判断加变量名和命令名混淆报command not found把变量名直接当命令写严格用$var引用[说实话我一度以为变量名和命令名混淆这个坑只有新手才踩结果发现老油条改代码也会踩。尤其是写长脚本的时候某个局部变量叫output下一行忘了加$直接写outputxxx就成了执行一个叫output的命令。写作业时务必把变量引用当成一种习惯不是可选动作。]5. 作业调试的正确方式从echo摸黑到bash -x可视化5.1 用echo打印关键状态写Shell脚本最原始也最有效的调试方式是打日志。我习惯在每个阶段开头打印一行标记信息echo [STEP 1] 开始扫描目录: $dir这样脚本跑完一遍看输出就能知道执行到哪个阶段挂掉的。如果某个阶段没打印标记说明问题就出在上一个标记和这个标记之间的代码里。配合变量值打印比如echo 当前处理文件: $file基本能定位90%的逻辑问题。5.2 bash -x是查脚本逻辑的神器在脚本没跑通的时候我强烈建议用bash -x执行整个脚本bash -x ./organize.sh -d /tmp/input这个命令会逐行显示脚本的执行过程每个命令执行前先打印出命令本身和变量展开后的真实值行首带符号的是Shell实际执行的命令。你写的是[ -d $dir ]展开出来是[ -d /tmp/input ]一眼就能看出判断条件是不是按你预期走的。有一次脚本总是不进入某个分支我肉眼看了半天没发现问题用bash -x跑了一遍才发现变量里多了一个看不见的空格导致字符串比较永远不相等。这种问题靠肉眼几乎不可能发现但bash -x输出里明明白白摆在那。5.3 利用退出码定位故障点每个命令执行完都会留下一个退出码存在$?变量里。0表示成功非0表示失败。在调试阶段我经常在关键步骤后面临时加一行打印退出码mv $file $new_name echo mv退出码: $?如果退出码不是0mv命令本身有错优先查源文件是否存在、目标目录是否可写。如果退出码是0但文件名不对那问题在生成new_name的逻辑里。这样的二分排查思路能把故障范围快速缩小。[我最常用的一套调试组合是bash -x跑整体流程配合脚本里的set -u和set -e两个选项。set -u让脚本在使用未定义变量时报错退出而不是默默当成空字符串继续跑。set -e让脚本在任意一条命令失败时直接退出。这两个选项加在脚本开头等于给脚本装了两道保险调试期间特别管用。不过要注意set -e有时会掩盖一些你想忽略的错误所以正式写工具时可以看情况关闭。]最后说几句这次作业的体会。第二次作业最大的价值不在于用了多高级的命令而在于逼着我把几十个命令行片段变成一个完整的、有逻辑的、能处理异常的系统。我踩过的这些坑——变量展开、grep退出码、shift消费参数、后台执行时read失效——每一条都是以后写任何Shell工具都会遇到的。如果你也在做类似的Shell作业我真的建议不要直接抄现成脚本亲手把bash -x跑一遍把每条报错查明白这个过程比脚本本身值钱得多。下次如果你的脚本在后台执行时突然卡住不动先想想它是不是在等一个永远等不到的输入——这个经验值我替你付过学费了希望你不用再付一次。