1. 这份shell笔记到底在记什么1.1 笔记的源起命令行日常里的“碎片化记录”这份笔记是我在2026年1月7日整理的一次阶段性记录没有特别宏大的主题就是把最近几周在shell环境里反复踩过的坑和确认过的命令细节集中写了一遍。说实话写shell笔记最开始是被逼出来的。以前总觉得自己用命令行很熟但每次隔上三五天不碰某项操作再去查资料就要重新翻一遍手册尤其是一些参数组合和引号嵌套当时能用、隔阵子再看就陌生。后来我养成了一个习惯遇到一个验证过、愿意以后继续复用的命令就立刻记下来标注使用场景和踩坑点。这次这篇笔记可以说是这个习惯在2026年年初的一次集中交底。做开发的人都知道操作系统的shell就像一张网把文件操作、进程管理、脚本自动化全串在一起。网上有大量零散的资料可是真到实战能救急的往往是你自己整理的那几行笔记。这份笔记我按命令类别来组织每一块都写清楚“什么时候用”“怎么写”“坑在哪里”后面再翻不至于重新瞎试。1.2 我整理笔记时坚持的三条原则先说第一条原则不记废话只记能让命令“跑得通结果又正确”的完整实例。很多教程喜欢大段地讲参数含义可命令行这东西光讲参数没用必须给一个能够直接跑的例子。我笔记里的每一条基本都有完整的命令行复制到终端里调整下路径就能用。第二条原则是记录“失败路径”。对比正常写法和错误写法的差别往往比单独看正确写法印象更深刻。比如find输出后面不加-print0直接接xargs遇到带空格的文件名整个管道就散了。我把这种失败场景原样记下来附上错误提示再写正确写法这样以后看到类似现象脑子里立刻就能对上号。第三条原则是控制笔记长度。整理笔记不是写书每一条最多三五行命令加一行备注能说明白问题就收手。太长的笔记反而不会去翻这个道理和写代码注释是一样的精简才有生命力。这些原则看起来简单但坚持下来之后我的命令行效率确实提升了不少。接下来几章我就按这份笔记的顺序把里面最值得展开的部分拿出来具体讲讲那些命令的细节、脚本调试的心得以及日常工具的组合玩法。2. 高频命令的细节坑参数写错一次就长记性2.1 grep与find组合时最容易翻车的三个场景第一个翻车场景是“文件名带空格”。我有一次想统计某个项目里所有日志文件中的关键字数量随手写了find ./logs -name *.log | xargs grep -c error看输出数字零零散散有的还是错误信息。原因很直接logs目录下有不少文件名带了日期和空格比如“2026-01-07 生产环境.log”。xargs默认按空白字符切分输入遇到空格就把一个文件名截成了两段find查出来的文件就匹配不到。正确写法是用-print0和-0组合find ./logs -name *.log -print0 | xargs -0 grep -c error-print0让find在文件名之间用空字符分隔空字符在文件名里不会出现xargs再加个-0按空字符切分这就是一对固定搭配。实测下来不管文件名里带空格、换行还是中文统统没问题。第二个场景和隐藏目录有关。想在项目目录里递归搜索某个函数名很多人喜欢用grep -r funcA ./但这个命令默认不会进入隐藏目录比如.git、.cache这些。你搜索半天觉得没结果其实函数就在某个隐藏子目录里。想真正按递归且包含隐藏目录的方式搜索我一般改用grep -r funcA ./ --include*.py并配合--exclude-dir.git这类排除项或者直接用find . -type f -print0 | xargs -0 grep funcA对目录结构掌控得更细。后来我新养成的习惯是搜代码优先用grep -R大写R它才会往下钻隐藏目录但也要小心会进.git这种巨大的目录所以排除规则一定要写好。第三个场景是搜索大文件时直接“把终端卡到怀疑人生”。有一次我在一个数据目录里执行grep -r 20260107 *结果终端直接卡住因为目录里有一个二十多GB的二进制数据文件grep不对二进制内容做判断一行一行地硬扫。后来我在笔记里增加了两个参数grep -r -I --exclude*.bin --exclude-dir{tmp,cache} 20260107 *-I表示忽略二进制文件配合--exclude把已知的大目录排除掉搜索速度立刻恢复正常。如果你不得不搜二进制文件建议先file确认类型再用strings把可打印字符提取出来接grep过滤效果比硬搜好得多。2.2 awk和sed的引号嵌套到底怎么理先看awk。awk程序本身通常要用单引号包住防止shell对$1、$2这类变量做展开。但问题来了如果我想在awk里执行一个shell命令比如按条件对某个字段做判断后执行外部命令就得用到双引号和单引号的组合。awk {print $1; system(echo $HOME)} data.txt这条命令里双引号内的$HOME是在awk的system调用里传给shell的实际会被shell展开。如果换成systme(echo $HOME)单引号会把shell变量挡在awk外面执行结果就不一样。我建议的原则是awk程序体里的静态文本用单引号包需要传给外部shell的变量用双引号显式拼接如果碰到变量要从awk字段里取则要先用-v参数把字段转成awk内部变量。sed的引号问题相对简单但花在分隔符上的心思要多一些。sed的替换语法是s/原/新/默认分隔符是斜杠可你要是处理路径、URL这类本身带斜杠的字符串整个表达式就成了转义地狱。举例把路径里的/usr/local替换成/optecho /usr/local/bin | sed s#/usr/local#/opt#这里用#当分隔符斜杠原样写阅读起来舒服多了。除了#还可以用|、等字符只要替换表达式里不会出现矛盾就行。sed还有一个我经常记不清的细节-i直接修改文件。有人写成sed -i s/foo/bar/ file.txt这在GNU版本下没问题但换到BSD版本-i后面必须跟一个备份后缀比如-i .bak否则直接报错。为了兼容或者为了安全我基本写成sed -i.bak s/foo/bar/ file.txt先留备份再替换确认没问题后删掉备份文件这个习惯帮我挽回过好多次误操作。2.3 特殊变量与默认值少看手册多踩坑shell里的特殊变量每一个都有明确的用途但有几个我反复记混后来干脆在笔记里做了一张对照表。$*和$在老式脚本里经常被混用。概括地说不加双引号时两者行为接近加了双引号后$*把全部参数拼成单个字符串$保留每个参数的独立性。比如遍历参数时用for arg in $参数里带空格也能正确处理用$*就彻底糊了。再看参数展开的默认值写法。这四个形式我写在笔记里写法作用典型场景${var:-default}var未设置或为空时返回default不改变var给变量提供可选默认值${var:default}var未设置或为空时设置var为default并返回希望变量之后也被赋值${var:?msg}var未设置或为空时打印msg并退出脚本强制校验必填参数${var:alt}var已设置且非空时返回alt否则返回空有值才输出提示信息有一次我写部署脚本忘记检查某环境变量是否存在结果路径解析成了空串命令直接去删了根目录下的临时目录。后面我学乖了对所有关键路径先做校验DEPLOY_DIR${DEPLOY_DIR:?环境变量DEPLOY_DIR必须设置}这么一行脚本启动时就立刻报错退出不会再带着空值往下跑。这个习惯特别适合那些“参数多、跑一次时间长”的自动化脚本。另外$$和$!也容易被忽略。$$表示当前shell的PID通常用来给临时文件命名比如/tmp/tmp_$$.log脚本一出错也能找到残留文件对应哪一次运行。$!表示最近一个后台进程的PID配合wait和kill做进程管理特别好用。这些变量在交互式终端里感知不强但一写脚本马上就离不开。3. 脚本调试与异常兜底从报错到定位的完整思路3.1 为什么我坚持在脚本开头写set -Eeuo pipefail以前写脚本喜欢“裸奔”反正终端里能跑就行。后来跑定时任务脚本只要中间一个小命令失败后面照常执行最后生成的结果文件不完整排查花了大半天。从那次起我的所有shell脚本开头基本固定成这样#!/usr/bin/env bash set -Eeuo pipefail逐一解释这四个选项理解之后你就知道不是玄学。-e表示脚本里只要出现命令返回非零状态立刻退出。这是最基础的“出错就停”策略避免失败命令带偏后续流程。但-e有个特性要注意它在某些情况下也会把你不想中断的“预期失败”给中断掉比如if cmd; then里的命令或被||接住的命令不会触发退出。-u表示使用未定义变量时立即报错退出。前面提到的空环境变量问题在这个选项下会被提前发现不再等到后面产生破坏性动作。-o pipefail解决的是管道退出码问题。默认情况下管道里最后一个命令的退出码才是整个管道的退出码。比如grep something nonexistent.txt | head -1grep失败但head成功管道退出码照旧是0。有pipefail管道里有任何一段失败整体就返回失败。这个选项在数据流水线脚本里特别重要。-E是让-e能覆盖到函数、子shell等更多场景和trap配合时尤其稳。当然这套组合不是万能的我踩过的坑是当脚本里某些命令明明会返回1但业务上是可以接受的比如grep -q pattern file没有匹配到内容时-e会直接让脚本退出我一般在判断前加一句if grep -q pattern file; then或! grep -q pattern file || true把状态“消化”掉。3.2 trap清理现场临时文件和后台进程的收尾脚本如果中途退出很容易留下两个“尾巴”临时文件和还在跑的后台进程。trap就是用来做收尾的。最常用的写法是TMP_FILE$(mktemp /tmp/script_XXXXXX.log) trap rm -f $TMP_FILE EXIT脚本不管正常结束还是中途退出EXIT信号都会触发清理动作临时文件基本不会再堆积。相比在脚本末尾清理trap的好处是即使中间有未预期的return或者set -e触发退出清理动作照样执行。再一个是后台进程的收尾。我写过一个小型并行采集脚本同时起好几个后台任务如果脚本被CtrlC中断后台任务会变成孤儿进程继续跑。处理方法是pids() trap kill ${pids[]} 2/dev/null INT TERM EXIT for job in task1 task2 task3; do run_job $job pids($!) done wait这里用数组记录所有后台PID收到中断信号后统一killwait等待所有任务结束。如果不加这层保护中断后那些进程还偷偷消耗资源得手动ps去翻很烦。3.3 调试时我常用的三招断点输出、伪执行与触发环境先说断点输出。很多脚本问题出在变量值和预想不一致我通常会在关键位置打印“标记变量”的组合echo [DEBUG] CURRENT_DIR$CURRENT_DIR, TARGET_FILE$TARGET_FILE 2注意输出通道要用2这样就算后续管道要处理stdout调试信息也不会混入主流程。这个习惯让我少看了很多乱码式的中间产物。第二招是伪执行。bash -n script.sh只检查语法不实际运行适合快速发现括号没闭合、函数定义写错这类低级错误。bash -x script.sh则会把每条命令及其展开结果打印到终端是定位逻辑问题的利器。bash -x配合上trap还有一个高级用法——只trace某一段set -x # 需要追踪的代码块 set x脚本里只对怀疑有问题的部分开启-x输出量小定位精准比整个脚本从头到尾打印一堆更能保持思路清晰。第三招是触发环境。脚本在交互终端里正常但放到crontab里跑就不对劲多半是环境变量缺失。因为cron继承的环境极其精简连PATH都很少包含自定义目录。调试方法是在脚本开头显式source你的环境配置文件或者干脆在脚本里重新定义PATH。我常写export PATH/usr/local/bin:/usr/bin:/bin:$PATH先把基础路径固定下来再跑后续命令避免脚本依赖用户交互环境的黑箱配置。这是我处理定时任务问题时最常用的一招也是最容易见效的一招。4. 管道、重定向与进程控制的组合玩法4.1 重定向顺序会影响执行结果别把和2写反shell命令执行时重定向的顺序是“从右往左”逐步生效的和直觉相反。常见写法python3 run.py out.log 21这个顺序是把stdout重定向到out.log然后“把文件描述符2重定向到文件描述符1当前的指向”最终stdout和stderr都进入out.log。如果反过来写python3 run.py 21 out.log效果完全不同。文件描述符2先被指到了当前stdout所在的地方还是终端然后stdout才被重定向到out.log。最终stderr留在终端上out.log里只有stdout这通常不是你想要的。所以固定搭配就是“先文件再21”。某些shell里也可以直接写一步到位把标准输出和错误输出都送到目标位置但由于不同shell历史兼容性的原因我在写要跨环境的脚本时仍然优先使用 file 21。还有一个容易忽略的点cmd的报错信息到底去哪里。假设你想看报错但脚本是在后台执行日志又写进文件结果是报错和正常输出混在一起。我一般会额外给日志加上时间戳和标记比如python3 run.py runner_$(date %Y%m%d).log 21这样每次运行都追加到当天日志排查问题时可以直接按时间线翻不用被覆盖。4.2 xargs的边界问题空格、引号与并行参数xargs是管道的好搭档但它的默认行为有几个坑。除了前面说的空格问题还有一个是引号问题xargs在切分参数时会解析引号如果你的文件名或参数里本身含引号会造成“二次拆分”。最稳妥的办法还是find ... -print0 | xargs -0 ...彻底绕开空白字符和引号语义让输入项原样传递。-0这个参数我说过很多次可能是因为踩坑次数最多的一个。再看分割参数的方式。xargs -n 1表示每次只拿一个参数执行命令适合按行处理的场景有时候希望一次命令吃进多个参数比如批量删除文件时find . -name *.tmp -print0 | xargs -0 -n 50 rm -f一次传50个参数给rm既避免了单条命令参数列表过长又能改善执行效率。不过参数数量也不能无脑放大要和系统单次exec参数上限几十万个字符保持距离。xargs -I {}用于占位符替换这个我用的也很多。比如批量重命名find . -name *.bak -print0 | xargs -0 -I {} mv {} {}.old{}在命令里出现几次都没问题xargs会把当前输入项替换进去适合那些不能简单地把参数追加在末尾的命令。如果你还需要并行执行xargs -P 4可以同时起多个进程。我做过一个小实验用xargs -P 8批量压缩图片速度比单进程快了将近六倍但负载瞬间也上去了所以-P要结合机器内核实测不要一上来就开满。4.3 后台任务与nohup的组合使用会话断了任务不能断在服务器上执行长任务最尴尬的是ssh会话一断任务就跟着没了。命令nohup的作用就是让进程忽略挂断信号配合后台运行nohup bash train.sh train_$(date %Y%m%d_%H%M%S).log 21 这里把脚本放到后台输出写进带时间戳的日志文件这样即使终端关闭任务也会继续跑而且日志文件时间戳清楚方便回头追踪。跑起来后我一般先看一眼任务状态ps -ef | grep train.sh | grep -v grep确认进程真的在跑之后再定期tail -f日志掌握进度。和后台任务相关的还有jobs、fg、bg这几个命令。交互式终端里CtrlZ可以把当前任务挂起bg %1把它放到后台跑fg %1切回前台。这套组合在处理单次执行时间较长的命令时很顺手但一旦离开当前终端jobs列表就没了所以在自动化脚本里我基本不依赖jobs而是全面使用PID记录nohup方案。进程管理还有一个细节是disown。如果后台任务已经启动你忘了加nohup那么用disown -h %1也可以把这个任务从当前shell的作业表中移除从而避免挂断时被清理。这个技巧比较小众但真到用的时候能救命。5. 日常效率工具与别名封装命令行真的能提速5.1 我高频使用的别名清单与说明别名alias是把常用命令缩写的最直接方式。我在~/.bashrc里维护了一个别名清单整理笔记时重新过了一遍挑出最常用的几个。别名完整命令说明llls -lhF人性化大小标记文件类型lals -Ah显示所有文件含隐藏但不含.和....cd ..省去cd...cd ../..上两级目录grepgrep --colorauto高亮匹配内容hhistory查看历史记录这里特别说一下ls -lhF-F会在目录后加/、可执行文件后加*扫一眼就知道对象类型信息量比普通ls大不少。alias的使用有两个禁忌一是别覆盖系统原有关键命令的默认行为比如给rm加-i能防误删但可能拖慢批量操作二是别在脚本里依赖alias脚本默认不展开alias你在交互终端配了别名脚本里用别名会直接报command not found。5.2 用函数封装代替别名传参才是硬道理别名最大的短板是不能优雅地接收参数。传参场景我把这类命令封装成函数写进bashrcmkcd() { mkdir -p $1 cd $1 || return }执行mkcd /home/foo/newproject先创建目录再进去无论成功失败都返回可观测的状态码。另一个我常用的封装是“快速定位日志里的错误并统计数量”errlog() { grep -n -E ERROR|FATAL|Exception $1 | tee (wc -l 2) }调用errlog app.log屏幕上能看到命中的行同时把数量打印到标准错误。这类带参数的封装别名完全做不到函数却非常顺手。函数定义后记得source ~/.bashrc或者重新打开终端才生效。我常在函数里加上防御判断比如参数个数不够时就打印用法说明mkcd() { if [ $# -ne 1 ]; then echo 用法: mkcd 目录路径 return 1 fi mkdir -p $1 cd $1 }这比裸写mkdir -p $1 cd $1严谨得多因为如果调用时忘记带参数$1是空串mkdir不会报错cd却会呆在原地脚本状态看起来怪怪的。5.3 历史命令检索少敲一遍是一遍命令行效率的另一个提升点是历史命令。!!表示上一条命令!$代表上一条命令的最后一个参数!*代表上一条命令的所有参数。我常用的场景是上一条命令只改了参数重跑直接在结尾加上!$比如vim /etc/nginx.conf chmod 644 !$第二个命令会把/etc/nginx.conf自动补到末尾。这里提个醒!类展开在某些shell里涉及交互模式脚本里是不会展开的如果要在脚本里传“上一条命令参数”直接用变量保存别指望这些历史符号。搜索历史命令用CtrlR在提示状态里输入关键字反复按CtrlR往回翻找到目标后回车执行。这个功能花不了多少时间但几乎每个命令行重度用户都在用。还有个小技巧设置HISTCONTROLignoreboth可以让以空格开头的命令不进历史记录方便你执行一些带敏感信息的命令时不留痕迹。如果还想加大历史容量调整HISTSIZE和HISTFILESIZE两个变量即可。6. 常见问题排查速查表遇到直接照方抓药6.1 变量赋值“失效”的三种情况第一种情况是管道里的子shell问题。执行echo hello | read name之后name变量在管道外还是空的这是因为每段管道命令默认在子shell里运行变量修改对父shell不可见。我见过不少人拿这个写循环结果变量一直为空排查半天。正确做法是用read name hello或进程替换read name (echo hello)。第二种情况是明明赋值了脚本其他函数里却读不到。多半是忘了export。普通变量只在当前shell可见子进程看不到必须用export导出到环境变量。注意export VARvalue和VARvalue有本质区别两个命令的执行环境完全不同。第三种情况是书写间隔导致的诡异问题。在VAR value这种写法里等号两边都有空格shell会把VAR当成一个命令来执行报command not found。很多人第一次接触shell会犯这个错排查时又不容易意识到因为终端里其他东西看起来都正常。6.2 脚本执行报错的定位套路脚本报错的定位流程我的经验是分成四步。第一步先用bash -n script.sh排除语法错误这个检查很快能筛掉一大半低级的括号、引号错误。第二步如果语法没问题用bash -x script.sh跑一个最小场景盯着命令展开后的输出找到第一个和预期不一致的行再往前推变量从哪里开始错的。第三步如果错误信息指向某一行但实际错误是从别的脚本里带出来的重点看函数调用关系。在同一行里写了函数调用和参数展开时某个变量是空值导致函数入口不对是一种常发现象这时在函数入口加个参数个数检查很快能暴露问题。第四步也是我最想强调的调整脚本后先做“边界验证”用一个小数据集跑一遍而不是直接上全量。比如脚本要处理一万个文件就先建一个只有三个文件的测试目录跑通后再全量。这个习惯节省的排查时间怎么估都不为过。6.3 环境变量不生效的经典场景经典的“环境变量不生效”场景是你在终端里手动声明了一个变量然后执行某个脚本这个脚本里打印变量却是空的。原因是脚本按bash script.sh方式执行时会启动一个子进程子进程不会自动继承没有export的普通变量。即使你用了export如果子进程还被某个代理程序重新初始化同样可能丢失。另一个经典场景是改了~/.bashrc但当前终端毫无变化。这是因为当前终端的配置已经在登录时加载过了新增内容不会主动刷新。执行一遍source ~/.bashrc或者直接新开一个终端才能生效。如果登录时发现配置没加载则要看是不是把配置写在~/.bash_profile里而不是~/.bashrc不同发行版、不同登录方式加载的配置文件不一样。在写交互式shell的依赖前我建议先确认当前shell是bash还是zsh否则配置写错地方问题非常隐蔽。还有一个常见场景是crontab脚本找不到命令。定时任务里的PATH和交互shell里的PATH差异很大导致脚本里写的python3或ffmpeg直接找不到。解决方式是在脚本开头显式指定PATH或者用命令的绝对路径。我通常优先显式声明PATH因为脚本里可能调多个命令逐个替换成绝对路径太难看。排查项可能原因快速验证方式变量在管道外为空子shell丢失改用here-string或进程替换子进程拿不到变量未export脚本开头echo $VAR测试source后仍不生效配置文件不对echo $SHELL确认检查login vs non-logincron里命令找不到PATH精简脚本开头添加export PATH这份速查表是我笔记的最后一页打印出来贴工位也不为过。不过说到底shell这东西还是靠练每多踩一次坑、多记一条心得后面就能少一次卡壳。希望这份笔记整理出来的细节能帮到你也欢迎你把它当作自己笔记的起点往里填更多实战经验。
1. 这份shell笔记到底在记什么1.1 笔记的源起命令行日常里的“碎片化记录”这份笔记是我在2026年1月7日整理的一次阶段性记录没有特别宏大的主题就是把最近几周在shell环境里反复踩过的坑和确认过的命令细节集中写了一遍。说实话写shell笔记最开始是被逼出来的。以前总觉得自己用命令行很熟但每次隔上三五天不碰某项操作再去查资料就要重新翻一遍手册尤其是一些参数组合和引号嵌套当时能用、隔阵子再看就陌生。后来我养成了一个习惯遇到一个验证过、愿意以后继续复用的命令就立刻记下来标注使用场景和踩坑点。这次这篇笔记可以说是这个习惯在2026年年初的一次集中交底。做开发的人都知道操作系统的shell就像一张网把文件操作、进程管理、脚本自动化全串在一起。网上有大量零散的资料可是真到实战能救急的往往是你自己整理的那几行笔记。这份笔记我按命令类别来组织每一块都写清楚“什么时候用”“怎么写”“坑在哪里”后面再翻不至于重新瞎试。1.2 我整理笔记时坚持的三条原则先说第一条原则不记废话只记能让命令“跑得通结果又正确”的完整实例。很多教程喜欢大段地讲参数含义可命令行这东西光讲参数没用必须给一个能够直接跑的例子。我笔记里的每一条基本都有完整的命令行复制到终端里调整下路径就能用。第二条原则是记录“失败路径”。对比正常写法和错误写法的差别往往比单独看正确写法印象更深刻。比如find输出后面不加-print0直接接xargs遇到带空格的文件名整个管道就散了。我把这种失败场景原样记下来附上错误提示再写正确写法这样以后看到类似现象脑子里立刻就能对上号。第三条原则是控制笔记长度。整理笔记不是写书每一条最多三五行命令加一行备注能说明白问题就收手。太长的笔记反而不会去翻这个道理和写代码注释是一样的精简才有生命力。这些原则看起来简单但坚持下来之后我的命令行效率确实提升了不少。接下来几章我就按这份笔记的顺序把里面最值得展开的部分拿出来具体讲讲那些命令的细节、脚本调试的心得以及日常工具的组合玩法。2. 高频命令的细节坑参数写错一次就长记性2.1 grep与find组合时最容易翻车的三个场景第一个翻车场景是“文件名带空格”。我有一次想统计某个项目里所有日志文件中的关键字数量随手写了find ./logs -name *.log | xargs grep -c error看输出数字零零散散有的还是错误信息。原因很直接logs目录下有不少文件名带了日期和空格比如“2026-01-07 生产环境.log”。xargs默认按空白字符切分输入遇到空格就把一个文件名截成了两段find查出来的文件就匹配不到。正确写法是用-print0和-0组合find ./logs -name *.log -print0 | xargs -0 grep -c error-print0让find在文件名之间用空字符分隔空字符在文件名里不会出现xargs再加个-0按空字符切分这就是一对固定搭配。实测下来不管文件名里带空格、换行还是中文统统没问题。第二个场景和隐藏目录有关。想在项目目录里递归搜索某个函数名很多人喜欢用grep -r funcA ./但这个命令默认不会进入隐藏目录比如.git、.cache这些。你搜索半天觉得没结果其实函数就在某个隐藏子目录里。想真正按递归且包含隐藏目录的方式搜索我一般改用grep -r funcA ./ --include*.py并配合--exclude-dir.git这类排除项或者直接用find . -type f -print0 | xargs -0 grep funcA对目录结构掌控得更细。后来我新养成的习惯是搜代码优先用grep -R大写R它才会往下钻隐藏目录但也要小心会进.git这种巨大的目录所以排除规则一定要写好。第三个场景是搜索大文件时直接“把终端卡到怀疑人生”。有一次我在一个数据目录里执行grep -r 20260107 *结果终端直接卡住因为目录里有一个二十多GB的二进制数据文件grep不对二进制内容做判断一行一行地硬扫。后来我在笔记里增加了两个参数grep -r -I --exclude*.bin --exclude-dir{tmp,cache} 20260107 *-I表示忽略二进制文件配合--exclude把已知的大目录排除掉搜索速度立刻恢复正常。如果你不得不搜二进制文件建议先file确认类型再用strings把可打印字符提取出来接grep过滤效果比硬搜好得多。2.2 awk和sed的引号嵌套到底怎么理先看awk。awk程序本身通常要用单引号包住防止shell对$1、$2这类变量做展开。但问题来了如果我想在awk里执行一个shell命令比如按条件对某个字段做判断后执行外部命令就得用到双引号和单引号的组合。awk {print $1; system(echo $HOME)} data.txt这条命令里双引号内的$HOME是在awk的system调用里传给shell的实际会被shell展开。如果换成systme(echo $HOME)单引号会把shell变量挡在awk外面执行结果就不一样。我建议的原则是awk程序体里的静态文本用单引号包需要传给外部shell的变量用双引号显式拼接如果碰到变量要从awk字段里取则要先用-v参数把字段转成awk内部变量。sed的引号问题相对简单但花在分隔符上的心思要多一些。sed的替换语法是s/原/新/默认分隔符是斜杠可你要是处理路径、URL这类本身带斜杠的字符串整个表达式就成了转义地狱。举例把路径里的/usr/local替换成/optecho /usr/local/bin | sed s#/usr/local#/opt#这里用#当分隔符斜杠原样写阅读起来舒服多了。除了#还可以用|、等字符只要替换表达式里不会出现矛盾就行。sed还有一个我经常记不清的细节-i直接修改文件。有人写成sed -i s/foo/bar/ file.txt这在GNU版本下没问题但换到BSD版本-i后面必须跟一个备份后缀比如-i .bak否则直接报错。为了兼容或者为了安全我基本写成sed -i.bak s/foo/bar/ file.txt先留备份再替换确认没问题后删掉备份文件这个习惯帮我挽回过好多次误操作。2.3 特殊变量与默认值少看手册多踩坑shell里的特殊变量每一个都有明确的用途但有几个我反复记混后来干脆在笔记里做了一张对照表。$*和$在老式脚本里经常被混用。概括地说不加双引号时两者行为接近加了双引号后$*把全部参数拼成单个字符串$保留每个参数的独立性。比如遍历参数时用for arg in $参数里带空格也能正确处理用$*就彻底糊了。再看参数展开的默认值写法。这四个形式我写在笔记里写法作用典型场景${var:-default}var未设置或为空时返回default不改变var给变量提供可选默认值${var:default}var未设置或为空时设置var为default并返回希望变量之后也被赋值${var:?msg}var未设置或为空时打印msg并退出脚本强制校验必填参数${var:alt}var已设置且非空时返回alt否则返回空有值才输出提示信息有一次我写部署脚本忘记检查某环境变量是否存在结果路径解析成了空串命令直接去删了根目录下的临时目录。后面我学乖了对所有关键路径先做校验DEPLOY_DIR${DEPLOY_DIR:?环境变量DEPLOY_DIR必须设置}这么一行脚本启动时就立刻报错退出不会再带着空值往下跑。这个习惯特别适合那些“参数多、跑一次时间长”的自动化脚本。另外$$和$!也容易被忽略。$$表示当前shell的PID通常用来给临时文件命名比如/tmp/tmp_$$.log脚本一出错也能找到残留文件对应哪一次运行。$!表示最近一个后台进程的PID配合wait和kill做进程管理特别好用。这些变量在交互式终端里感知不强但一写脚本马上就离不开。3. 脚本调试与异常兜底从报错到定位的完整思路3.1 为什么我坚持在脚本开头写set -Eeuo pipefail以前写脚本喜欢“裸奔”反正终端里能跑就行。后来跑定时任务脚本只要中间一个小命令失败后面照常执行最后生成的结果文件不完整排查花了大半天。从那次起我的所有shell脚本开头基本固定成这样#!/usr/bin/env bash set -Eeuo pipefail逐一解释这四个选项理解之后你就知道不是玄学。-e表示脚本里只要出现命令返回非零状态立刻退出。这是最基础的“出错就停”策略避免失败命令带偏后续流程。但-e有个特性要注意它在某些情况下也会把你不想中断的“预期失败”给中断掉比如if cmd; then里的命令或被||接住的命令不会触发退出。-u表示使用未定义变量时立即报错退出。前面提到的空环境变量问题在这个选项下会被提前发现不再等到后面产生破坏性动作。-o pipefail解决的是管道退出码问题。默认情况下管道里最后一个命令的退出码才是整个管道的退出码。比如grep something nonexistent.txt | head -1grep失败但head成功管道退出码照旧是0。有pipefail管道里有任何一段失败整体就返回失败。这个选项在数据流水线脚本里特别重要。-E是让-e能覆盖到函数、子shell等更多场景和trap配合时尤其稳。当然这套组合不是万能的我踩过的坑是当脚本里某些命令明明会返回1但业务上是可以接受的比如grep -q pattern file没有匹配到内容时-e会直接让脚本退出我一般在判断前加一句if grep -q pattern file; then或! grep -q pattern file || true把状态“消化”掉。3.2 trap清理现场临时文件和后台进程的收尾脚本如果中途退出很容易留下两个“尾巴”临时文件和还在跑的后台进程。trap就是用来做收尾的。最常用的写法是TMP_FILE$(mktemp /tmp/script_XXXXXX.log) trap rm -f $TMP_FILE EXIT脚本不管正常结束还是中途退出EXIT信号都会触发清理动作临时文件基本不会再堆积。相比在脚本末尾清理trap的好处是即使中间有未预期的return或者set -e触发退出清理动作照样执行。再一个是后台进程的收尾。我写过一个小型并行采集脚本同时起好几个后台任务如果脚本被CtrlC中断后台任务会变成孤儿进程继续跑。处理方法是pids() trap kill ${pids[]} 2/dev/null INT TERM EXIT for job in task1 task2 task3; do run_job $job pids($!) done wait这里用数组记录所有后台PID收到中断信号后统一killwait等待所有任务结束。如果不加这层保护中断后那些进程还偷偷消耗资源得手动ps去翻很烦。3.3 调试时我常用的三招断点输出、伪执行与触发环境先说断点输出。很多脚本问题出在变量值和预想不一致我通常会在关键位置打印“标记变量”的组合echo [DEBUG] CURRENT_DIR$CURRENT_DIR, TARGET_FILE$TARGET_FILE 2注意输出通道要用2这样就算后续管道要处理stdout调试信息也不会混入主流程。这个习惯让我少看了很多乱码式的中间产物。第二招是伪执行。bash -n script.sh只检查语法不实际运行适合快速发现括号没闭合、函数定义写错这类低级错误。bash -x script.sh则会把每条命令及其展开结果打印到终端是定位逻辑问题的利器。bash -x配合上trap还有一个高级用法——只trace某一段set -x # 需要追踪的代码块 set x脚本里只对怀疑有问题的部分开启-x输出量小定位精准比整个脚本从头到尾打印一堆更能保持思路清晰。第三招是触发环境。脚本在交互终端里正常但放到crontab里跑就不对劲多半是环境变量缺失。因为cron继承的环境极其精简连PATH都很少包含自定义目录。调试方法是在脚本开头显式source你的环境配置文件或者干脆在脚本里重新定义PATH。我常写export PATH/usr/local/bin:/usr/bin:/bin:$PATH先把基础路径固定下来再跑后续命令避免脚本依赖用户交互环境的黑箱配置。这是我处理定时任务问题时最常用的一招也是最容易见效的一招。4. 管道、重定向与进程控制的组合玩法4.1 重定向顺序会影响执行结果别把和2写反shell命令执行时重定向的顺序是“从右往左”逐步生效的和直觉相反。常见写法python3 run.py out.log 21这个顺序是把stdout重定向到out.log然后“把文件描述符2重定向到文件描述符1当前的指向”最终stdout和stderr都进入out.log。如果反过来写python3 run.py 21 out.log效果完全不同。文件描述符2先被指到了当前stdout所在的地方还是终端然后stdout才被重定向到out.log。最终stderr留在终端上out.log里只有stdout这通常不是你想要的。所以固定搭配就是“先文件再21”。某些shell里也可以直接写一步到位把标准输出和错误输出都送到目标位置但由于不同shell历史兼容性的原因我在写要跨环境的脚本时仍然优先使用 file 21。还有一个容易忽略的点cmd的报错信息到底去哪里。假设你想看报错但脚本是在后台执行日志又写进文件结果是报错和正常输出混在一起。我一般会额外给日志加上时间戳和标记比如python3 run.py runner_$(date %Y%m%d).log 21这样每次运行都追加到当天日志排查问题时可以直接按时间线翻不用被覆盖。4.2 xargs的边界问题空格、引号与并行参数xargs是管道的好搭档但它的默认行为有几个坑。除了前面说的空格问题还有一个是引号问题xargs在切分参数时会解析引号如果你的文件名或参数里本身含引号会造成“二次拆分”。最稳妥的办法还是find ... -print0 | xargs -0 ...彻底绕开空白字符和引号语义让输入项原样传递。-0这个参数我说过很多次可能是因为踩坑次数最多的一个。再看分割参数的方式。xargs -n 1表示每次只拿一个参数执行命令适合按行处理的场景有时候希望一次命令吃进多个参数比如批量删除文件时find . -name *.tmp -print0 | xargs -0 -n 50 rm -f一次传50个参数给rm既避免了单条命令参数列表过长又能改善执行效率。不过参数数量也不能无脑放大要和系统单次exec参数上限几十万个字符保持距离。xargs -I {}用于占位符替换这个我用的也很多。比如批量重命名find . -name *.bak -print0 | xargs -0 -I {} mv {} {}.old{}在命令里出现几次都没问题xargs会把当前输入项替换进去适合那些不能简单地把参数追加在末尾的命令。如果你还需要并行执行xargs -P 4可以同时起多个进程。我做过一个小实验用xargs -P 8批量压缩图片速度比单进程快了将近六倍但负载瞬间也上去了所以-P要结合机器内核实测不要一上来就开满。4.3 后台任务与nohup的组合使用会话断了任务不能断在服务器上执行长任务最尴尬的是ssh会话一断任务就跟着没了。命令nohup的作用就是让进程忽略挂断信号配合后台运行nohup bash train.sh train_$(date %Y%m%d_%H%M%S).log 21 这里把脚本放到后台输出写进带时间戳的日志文件这样即使终端关闭任务也会继续跑而且日志文件时间戳清楚方便回头追踪。跑起来后我一般先看一眼任务状态ps -ef | grep train.sh | grep -v grep确认进程真的在跑之后再定期tail -f日志掌握进度。和后台任务相关的还有jobs、fg、bg这几个命令。交互式终端里CtrlZ可以把当前任务挂起bg %1把它放到后台跑fg %1切回前台。这套组合在处理单次执行时间较长的命令时很顺手但一旦离开当前终端jobs列表就没了所以在自动化脚本里我基本不依赖jobs而是全面使用PID记录nohup方案。进程管理还有一个细节是disown。如果后台任务已经启动你忘了加nohup那么用disown -h %1也可以把这个任务从当前shell的作业表中移除从而避免挂断时被清理。这个技巧比较小众但真到用的时候能救命。5. 日常效率工具与别名封装命令行真的能提速5.1 我高频使用的别名清单与说明别名alias是把常用命令缩写的最直接方式。我在~/.bashrc里维护了一个别名清单整理笔记时重新过了一遍挑出最常用的几个。别名完整命令说明llls -lhF人性化大小标记文件类型lals -Ah显示所有文件含隐藏但不含.和....cd ..省去cd...cd ../..上两级目录grepgrep --colorauto高亮匹配内容hhistory查看历史记录这里特别说一下ls -lhF-F会在目录后加/、可执行文件后加*扫一眼就知道对象类型信息量比普通ls大不少。alias的使用有两个禁忌一是别覆盖系统原有关键命令的默认行为比如给rm加-i能防误删但可能拖慢批量操作二是别在脚本里依赖alias脚本默认不展开alias你在交互终端配了别名脚本里用别名会直接报command not found。5.2 用函数封装代替别名传参才是硬道理别名最大的短板是不能优雅地接收参数。传参场景我把这类命令封装成函数写进bashrcmkcd() { mkdir -p $1 cd $1 || return }执行mkcd /home/foo/newproject先创建目录再进去无论成功失败都返回可观测的状态码。另一个我常用的封装是“快速定位日志里的错误并统计数量”errlog() { grep -n -E ERROR|FATAL|Exception $1 | tee (wc -l 2) }调用errlog app.log屏幕上能看到命中的行同时把数量打印到标准错误。这类带参数的封装别名完全做不到函数却非常顺手。函数定义后记得source ~/.bashrc或者重新打开终端才生效。我常在函数里加上防御判断比如参数个数不够时就打印用法说明mkcd() { if [ $# -ne 1 ]; then echo 用法: mkcd 目录路径 return 1 fi mkdir -p $1 cd $1 }这比裸写mkdir -p $1 cd $1严谨得多因为如果调用时忘记带参数$1是空串mkdir不会报错cd却会呆在原地脚本状态看起来怪怪的。5.3 历史命令检索少敲一遍是一遍命令行效率的另一个提升点是历史命令。!!表示上一条命令!$代表上一条命令的最后一个参数!*代表上一条命令的所有参数。我常用的场景是上一条命令只改了参数重跑直接在结尾加上!$比如vim /etc/nginx.conf chmod 644 !$第二个命令会把/etc/nginx.conf自动补到末尾。这里提个醒!类展开在某些shell里涉及交互模式脚本里是不会展开的如果要在脚本里传“上一条命令参数”直接用变量保存别指望这些历史符号。搜索历史命令用CtrlR在提示状态里输入关键字反复按CtrlR往回翻找到目标后回车执行。这个功能花不了多少时间但几乎每个命令行重度用户都在用。还有个小技巧设置HISTCONTROLignoreboth可以让以空格开头的命令不进历史记录方便你执行一些带敏感信息的命令时不留痕迹。如果还想加大历史容量调整HISTSIZE和HISTFILESIZE两个变量即可。6. 常见问题排查速查表遇到直接照方抓药6.1 变量赋值“失效”的三种情况第一种情况是管道里的子shell问题。执行echo hello | read name之后name变量在管道外还是空的这是因为每段管道命令默认在子shell里运行变量修改对父shell不可见。我见过不少人拿这个写循环结果变量一直为空排查半天。正确做法是用read name hello或进程替换read name (echo hello)。第二种情况是明明赋值了脚本其他函数里却读不到。多半是忘了export。普通变量只在当前shell可见子进程看不到必须用export导出到环境变量。注意export VARvalue和VARvalue有本质区别两个命令的执行环境完全不同。第三种情况是书写间隔导致的诡异问题。在VAR value这种写法里等号两边都有空格shell会把VAR当成一个命令来执行报command not found。很多人第一次接触shell会犯这个错排查时又不容易意识到因为终端里其他东西看起来都正常。6.2 脚本执行报错的定位套路脚本报错的定位流程我的经验是分成四步。第一步先用bash -n script.sh排除语法错误这个检查很快能筛掉一大半低级的括号、引号错误。第二步如果语法没问题用bash -x script.sh跑一个最小场景盯着命令展开后的输出找到第一个和预期不一致的行再往前推变量从哪里开始错的。第三步如果错误信息指向某一行但实际错误是从别的脚本里带出来的重点看函数调用关系。在同一行里写了函数调用和参数展开时某个变量是空值导致函数入口不对是一种常发现象这时在函数入口加个参数个数检查很快能暴露问题。第四步也是我最想强调的调整脚本后先做“边界验证”用一个小数据集跑一遍而不是直接上全量。比如脚本要处理一万个文件就先建一个只有三个文件的测试目录跑通后再全量。这个习惯节省的排查时间怎么估都不为过。6.3 环境变量不生效的经典场景经典的“环境变量不生效”场景是你在终端里手动声明了一个变量然后执行某个脚本这个脚本里打印变量却是空的。原因是脚本按bash script.sh方式执行时会启动一个子进程子进程不会自动继承没有export的普通变量。即使你用了export如果子进程还被某个代理程序重新初始化同样可能丢失。另一个经典场景是改了~/.bashrc但当前终端毫无变化。这是因为当前终端的配置已经在登录时加载过了新增内容不会主动刷新。执行一遍source ~/.bashrc或者直接新开一个终端才能生效。如果登录时发现配置没加载则要看是不是把配置写在~/.bash_profile里而不是~/.bashrc不同发行版、不同登录方式加载的配置文件不一样。在写交互式shell的依赖前我建议先确认当前shell是bash还是zsh否则配置写错地方问题非常隐蔽。还有一个常见场景是crontab脚本找不到命令。定时任务里的PATH和交互shell里的PATH差异很大导致脚本里写的python3或ffmpeg直接找不到。解决方式是在脚本开头显式指定PATH或者用命令的绝对路径。我通常优先显式声明PATH因为脚本里可能调多个命令逐个替换成绝对路径太难看。排查项可能原因快速验证方式变量在管道外为空子shell丢失改用here-string或进程替换子进程拿不到变量未export脚本开头echo $VAR测试source后仍不生效配置文件不对echo $SHELL确认检查login vs non-logincron里命令找不到PATH精简脚本开头添加export PATH这份速查表是我笔记的最后一页打印出来贴工位也不为过。不过说到底shell这东西还是靠练每多踩一次坑、多记一条心得后面就能少一次卡壳。希望这份笔记整理出来的细节能帮到你也欢迎你把它当作自己笔记的起点往里填更多实战经验。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
