写这篇速查手册的起因是我这几年经常要跨机器、跨项目地临时写脚本——处理日志、批量改文件名、检查服务状态、定时备份数据。Shell 的语法说简单也简单说复杂也复杂大多数时候就是变量、循环、判断加上几条常用命令拼装但真正到了写的时候总有细节记不牢$和$*到底差在哪、shift怎么配合参数解析用、字符串截取有哪几种写法、set -e为什么会把好好的脚本搞挂。每次卡住都得翻旧脚本或者现查文档特别浪费时间。所以我把高频用到的 Shell 语法整理成了一份速查笔记这篇文章就是这份笔记的公开版按变量、流程、字符串、函数、调试、排坑这几个维度组织方便直接当手册查阅。适合谁看如果你刚开始做 shell 脚本入门这份手册能帮你快速搭起语法框架搞清楚每个语法点在实际场景里的用途如果你已经写了不少脚本这里整理的细节和坑大概率能帮你省下一些调试时间尤其是 2.2 节 for 循环的几种形态和 6.1 节的排坑表都是我自己踩过之后才写进去的。1. 变量与参数传递基础语法1.1 变量定义与使用的关键细节Shell 变量定义有个新手第一眼就容易踩的规则等号两边不能有空格。name hello会被解析成执行命令name传入参数和hello然后报command not found。正确写法是namehello。这个规则不是编译器限制而是 shell 的 token 切分逻辑决定的——空格在命令行里天然是参数分隔符所以等号紧贴着变量名才能被识别成赋值语句。变量使用时要加$前缀写echo $name或者更严谨的${name}都行。这里建议从第一天起就养成写${name}的习惯。原因很实际当变量后面紧跟着其他字符时比如要拼接字符串${name}_2024.log如果你写成$name_2024.logshell 会尝试找名为name_2024的变量结果为空脚本就静默出错。这种错误不会直接报错排查起来特别费劲。除了普通变量还有几个常用的位置参数需要熟悉$0 # 脚本本身的名称 $1 $2 # 第一个、第二个位置参数 $# # 参数个数 $ # 所有参数每个参数独立 $* # 所有参数合并成一个字符串 $? # 上一条命令的退出码 $$ # 当前进程 PID$和$*这对是最容易被忽视的。不加引号时两者表现一样但加了引号就有本质区别$会把每个参数原样保留等价于分别传递每个参数$*会把所有参数拼成一个带空格的字符串。写脚本转发参数时一定要用$不然参数里的空格会被二次拆分导致语义变化。举个真实例子我写过批量处理脚本参数里带有空格的文件名一开始用的$*传给下游函数结果文件名全被拆成了两半改成$后问题立刻消失。1.2 shift 命令的用途与参数解析shift命令的作用是让所有位置参数向左移动一位原来$2变成$1$1被丢弃同时$#减一。这玩意儿单独看很简单但它是手写参数解析的核心工具。最常见的场景是解析带选项的参数比如./deploy.sh -e prod -v 2.1.0。用shift配合case可以写出清晰的解析逻辑#!/bin/bash envdev versionlatest while [ $# -gt 0 ]; do case $1 in -e|--env) env$2 shift 2 ;; -v|--version) version$2 shift 2 ;; -h|--help) echo Usage: $0 [-e env] [-v version] exit 0 ;; *) echo Unknown option: $1 exit 1 ;; esac doneshift 2表示一次移动两位把选项名和它的值一起跳过。这里要注意边界情况如果用户只写了-e而没有给值$2就是空的判断时容易漏。稳妥的做法是在取$2之前先确认$# -ge 2或者用getopts来兜底。对于简单场景我习惯手写while加shift因为可读性好逻辑完全可控参数多了才换getopts这类工具。还有一个实用细节shift可以带数字直接跳过多个参数但跳过的数量不能超过当前参数个数否则脚本会报shift count out of range循环里使用时要留意。2. 条件判断与流程控制语法2.1 if 判断的写法与常见坑Shell 的if判断写起来和其他语言风格差异很大核心是[ ]这个测试命令和[[ ]]这个关键字。先说推荐写新脚本用[[ ]]它是 bash 的内置关键字支持、||、正则匹配~而且对空变量更宽容不会出现[在变量为空时报语法错的经典问题。if [[ -f $file ]]; then echo 文件存在 elif [[ -z $var ]]; then echo 变量为空 else echo 其他情况 fi几个常用判断操作符做个速查操作符含义场景示例-f是否为普通文件判断配置文件是否存在-d是否为目录判断输出目录是否已创建-z字符串长度是否为 0判断参数是否为空-n字符串长度是否非 0判断变量是否有值-eq数字相等数值比较-lt数字小于数值比较字符串相等字符串比较[[ ]]里用也行-e文件或目录是否存在通用存在性检查这里最隐蔽的坑是数字和字符串的比较不能混用。[ $a -eq $b ]是数字比较[ $a $b ]是字符串比较。如果把数字比较写成[ $a $b ]在a10、b2时结果是不相等这没问题但如果写反了用-eq比较字符串abc和abcshell 会尝试把abc解析成数字报integer expression expected的错。还有一点[ ]里面每个操作符、变量、符号之间必须用空格隔开[ $a$b ]这样连着写会被当成一个整体字符串判断结果永远是 false。这个错误我在初学者代码里见过不下十次。2.2 for 循环的几种形态for是 Shell 脚本里出现频率最高的循环它的形态比大多数语言丰富我按使用频次排个序第一种遍历列表for ip in 192.168.1.1 192.168.1.2 192.168.1.3; do ping -c 1 $ip /dev/null 21 echo $ip 可达 || echo $ip 不可达 done第二种遍历命令输出的结果for log in $(ls *.log); do echo 处理 $log done这里要提醒一个经典问题$(ls *.log)这种方式一旦文件名里有空格就会被拆成多个元素导致逻辑出错。更稳的写法是用通配符直接展开for log in *.log; do echo 处理 $log done通配符展开是在 shell 层面完成的每个文件名天然作为一个整体空格不会造成干扰。如果日志文件在不同目录层级可以配合find加while read来做这个我在 2.3 节展开。第三种C 风格的数值循环for ((i1; i10; i)); do echo $i done这种适合明确知道循环次数、需要用到计数器变量的场景比如重试机制、生成序号文件。我在写重试逻辑时经常用它循环里执行命令判断退出码成功就 break失败就sleep一段时间继续最多重试 5 次。还有一个容易被忽略的写法是for i in {1..10}花括号展开可以生成连续序列。{1..10}和{a..z}都支持还支持步长{1..10..2}。不过要注意花括号展开不能用于变量for i in {$start..$end}是不生效的这种情况就得用seq命令或者 C 风格循环。2.3 while 与 case 的实际用法while最典型的两个场景一个是按行读取文件另一个是配合shift解析参数1.2 节已经写过。按行读取文件的标准写法是while IFS read -r line; do echo 当前行: $line done input.txt这里IFS的意思是清空内部字段分隔符防止行首行尾的空白被修剪-r防止反斜杠被当作转义字符处理。这两个细节缺一不可否则读出来的内容和原文不一致。如果你要处理的是find的输出安全做法是find . -name *.log -print0 | while IFS read -r -d file; do echo 发现文件: $file done-print0和-d 搭配用空字符而不是换行分隔可以处理任意怪异的文件名包括带换行符的文件名——虽然这种文件很少见但防御一下没坏处。case在 Shell 里的地位相当于其他语言里的switch。它的一个优势是支持通配符模式可以让匹配逻辑非常简洁case $1 in start) echo 启动服务 ;; stop|kill) echo 停止服务 ;; restart) echo 重启服务 ;; *) echo 用法: $0 {start|stop|restart} exit 1 ;; esac写case时最容易漏的是;;每个分支结束必须带两个分号最后那个*通配分支用来兜底处理未匹配的情况。另外case配合shift做参数解析就是很多命令行工具内部的实际实现方式理解了这个组合读开源脚本会容易很多。until和while是反着的条件为假时执行循环体条件为真时退出。实际用得少但有一个场景挺合适等待某个服务就绪。until curl -s http://localhost:8080/health /dev/null 21; do echo 服务未就绪等待 2 秒... sleep 2 done这种写法比while !可读性好一些语义上直到服务就绪才继续更自然。3. 字符串处理与运算语法3.1 字符串截取、替换与拼接字符串操作是 Shell 语法里性价比最高的部分掌握几个核心写法几乎能覆盖日常所有需求。截取子串用的是${var:起始位置:长度}从 0 开始计数str2024-11-15_nginx.log echo ${str:0:10} # 输出 2024-11-15 echo ${str:11:5} # 输出 nginx删除前缀后缀、替换用的是#、%和/这些符号速查如下filearchive.tar.gz echo ${file%.tar.gz} # 删除后缀输出 archive echo ${file%%.*} # 从最后一个点开始删输出 archive echo ${file#*.} # 删除第一个点之前的内容输出 tar.gz echo ${file##*.} # 从最后一个点开始删前缀输出 gz echo ${file/.tar.gz/.zip} # 替换第一个匹配输出 archive.zip echo ${file//./_} # 替换所有匹配输出 archive_tar_gz这组符号的规律很好记#是从左边开头开始删除匹配%是从右边结尾开始删除匹配单个符号是最短匹配双符号是最长匹配。「最短匹配」的含义是让模式匹配到的内容尽可能少所以${file%.*}删掉的是最后一个点之后的内容得到archive.tar而${file%%.*}用最长匹配删掉从第一个点开始的所有内容。知道这个规律碰到类似需求基本不用查表。变量默认值处理也是高频需求。部署脚本里经常要环境变量没设置就给默认值env${ENV:-dev}${var:-默认值}在变量未设置或为空时使用默认值${var:默认值}除了使用默认值还会把默认值赋值给变量。这两个的差别很小但有时候就靠它省好几行判断。还有${var:?错误信息}如果变量为空就打印错误信息并退出适合关键参数检查。3.2 日期时间处理与文件名拼接脚本里处理时间戳和日期特别频繁尤其在写日志归档、备份任务的时候。date命令是核心工具先看几个常用格式date %Y-%m-%d # 2024-11-15日期 date %Y-%m-%d %H:%M:%S # 2024-11-15 14:30:22带时间 date %Y%m%d%H%M%S # 20241115143022纯数字串 date %s # 1729056622Unix 时间戳前面搜索词里提到的shell脚本获取当前日期时间并转换为数字串其实就是上面第三行的写法。数字串的好处是适合直接拼进文件名做排序键比如backup_20241115143022.tar.gz按字典序排序就是按时间排序归档管理非常方便。取昨天的日期、一周前的时间用-ddate -d yesterday %Y-%m-%d date -d 7 days ago %Y-%m-%d date -d 2024-11-15 -1 day %Y-%m-%d在 Linux 上这些写法都能用但 macOS 的date是 BSD 风格-d参数不存在需要用date -v-1d %Y-%m-%d。跨平台脚本里我会先判断系统类型再走不同分支或者干脆统一用python3 -c来生成日期不过为了一个小功能引入 Python 有点重大多数时候还是分平台处理。时间戳和日期互转也是常用操作date -d 1729056622 %Y-%m-%d %H:%M:%S这个在解析日志文件里那种纯数字时间戳时很好用。注意如果你的日志时间戳是毫秒级要先除以 1000 或者用awk截掉后三位再喂给date。还有时区问题服务器默认 UTC 的话转出来的时间会和本地时间差 8 个小时生产环境脚本里要么统一用TZ环境变量指定TZAsia/Shanghai date %Y-%m-%d %H:%M:%S要么在文档里写明服务器的时区假设不然排查线上问题时会绕很大弯子。3.3 数值运算与算术扩展Shell 里做整数运算标准写法是$(( ))total$((count 1)) bytes$((size * 1024))注意几点算术表达式里的变量不需要加$前缀$((count 1))和$(( $count 1 ))都可以但前者更简洁。除法是整数除法echo $((7/2))结果是 3不会给你 3.5。要做小数运算就得用awk或者bcecho scale2; 7/2 | bc # 输出 3.50bc的scale控制小数位数但除法必须显式设scale才生效默认是 0这又是一个容易踩的细节。自增自减写成((i))或((i1))。老实说 Shell 的数值运算能力比较弱超过简单的计数和字节换算我基本就直接调awk或python3了硬要用 Shell 写复杂计算是跟自己的时间过不去。不过有一个技巧值得提printf可以做数字格式化补零printf %02d 3 # 输出 03配合循环生成带序号的零填充文件名比如image_001.jpg到image_099.jpg比手工拼字符串清爽得多。4. 函数、退出码与脚本调试4.1 函数定义与返回值处理Shell 函数的定义很简单两种写法等价function log_info { echo [INFO] $1 } log_error() { echo [ERROR] $1 2 }函数里的$1、$2是函数的参数不是脚本的参数这个要分清楚。如果函数想用脚本的全局参数得在外面先存成全局变量或者在调用时显式传进去。函数的返回值很多人一开始会被误导。Shell 函数里的return只能返回整数退出码0 到 255不能返回字符串。想要函数输出一个字符串并让调用方拿到靠的是标准输出配合命令替换get_env_name() { if [[ $APP_ENV ]]; then echo dev else echo $APP_ENV fi } env_name$(get_env_name)这里echo输出的内容会被$( )捕获并赋值给变量。一个常见的坑是如果函数里除了主要输出之外还有别的echo比如调试信息这些信息也会被$( )一起捕获导致变量内容变脏。调试信息只用2输出到标准错误或者用set x临时关掉跟踪就不会污染返回值。return的退出码怎么用配合if直接判断check_port() { local port$1 if ss -tln | grep -q :$port ; then return 0 fi return 1 } if check_port 8080; then echo 端口已被占用 fi这种写法比if [[ $(check_port 8080) 0 ]]优雅多了因为if判断的就是命令的退出码。写函数时养成成功return 0失败return 1的习惯整个脚本的可组合性会大大提升。4.2 退出码与 set 选项$?记录上一条命令的退出码0表示成功非0表示失败。这个机制很基础但用好它能写出健壮得多的脚本。我见过太多人写了脚本中间命令失败了还硬着头皮继续跑最后产出的结果全是错的。解决办法就是set -e。set -e的含义是脚本中任何一条命令返回非 0 退出码立即终止执行。它让脚本从尽力执行变成失败即停部署、备份这类脚本尤其需要。但set -e也有两个反直觉的点第一被if条件、while条件、/||连接的命令不受影响。if grep -q error $log; then里grep 即使没匹配到返回 1脚本也不会退出。这是设计使然但新人不了解的话会以为set -e失灵了。第二set -e在某些管道组合下会失效除非配合set -o pipefail。pipefail让管道返回最后一个非 0 退出码而不是默认记录的管道最后一条命令的退出码。set -e set -o pipefail这两行加在脚本开头是很多生产环境脚本的标配。再加一个set -u变量未定义即报错退出能揪出一堆拼写错误的变量名。我这几年写脚本的固定开头是#!/bin/bash set -euo pipefail-u有个小不便$#为 0 时访问$1会报错所以涉及参数判断的脚本要在set -u后面先做好参数数量检查或者用${1:-}提供默认值。4.3 脚本调试技巧调试 Shell 脚本不是靠猜的bash -x是最好用的工具。执行时加上-x每一行命令执行前都会把展开后的内容打印出来等于给你一张它到底执行了什么的全过程记录。bash -x deploy.sh更精细一点的可以在脚本内部用set -x临时开启、set x关闭跟踪只跟踪问题段落。另一个常用的是bash -n只做语法检查不执行写完长脚本先跑一遍bash -n能把语法错误提前暴露。配合echo打印关键变量值、用2输出调试信息到标准错误排查思路就清晰多了。我个人的调试习惯是三步走先bash -n检查语法再bash -x跑一遍看完整执行轨迹最后在可疑的赋值语句后面临时加一行echo DEBUG: var$var确认中间值。三个步骤下来九成的问题都能定位。还有一个小技巧trap可以在脚本退出或报错时打印信息trap echo 脚本在 line $LINENO 出错, 退出码: $? ERR配合set -e使用脚本出错时会自动打出出错的行号和退出码这在跑长任务时特别救命不用等任务失败后再翻日志找原因。5. 文本处理常用语法组合5.1 grep、awk、sed 三件套速用写 Shell 脚本绕不开文本处理而文本处理的三件套就是grep、awk、sed。这三个工具的语法都不复杂但组合起来能高效解决大量问题比用 Python 写一小段处理要省事得多。grep负责筛选行。常用参数-E开启扩展正则、-v反向匹配、-q安静模式只判断是否有匹配、-c统计匹配行数。最常用的组合是日志里过滤关键字并排除干扰项grep -E ERROR|FATAL app.log | grep -v heartbeatawk负责按列处理。默认按空格切分列$1、$2分别代表第一列、第二列NF是列数NR是行号。一个经典需求打印日志里响应时间超过 5 秒的请求awk $NF 5 {print $1, $2, $NF} access.logawk的语法本质上是一门小语言有BEGIN、END、条件表达式、内置变量。不过对大多数脚本场景来说会写按列取值 数值比较 print已经能解决八成需求。需要小心的是列分隔符日志里如果是用|或,分隔要用-F指定awk -F| {print $1, $3} data.txtsed负责行内替换和删除。最常见的用法是去掉首尾空格、替换字符串sed -i s/old/new/g config.conf echo hello | sed s/^[ \t]*//;s/[ \t]*$//-i是原地修改文件在 macOS 上要写成sed -i 否则会报错。替换里的g表示全局替换不加只替换每行第一个匹配。还有一个很实用的小技巧sed -n 10,20p可以只查看文件的第 10 到 20 行排查长配置文件时省得开编辑器。5.2 管道与重定向的正确打开方式管道|把前一个命令的输出传给后一个命令作为输入。理解它的关键是管道传的是文本流而不是变量。所以你不能写echo $ | var$(cat)这样试图把管道输出赋值给同一条命令里的变量的代码因为管道的左右两边一般会被 shell 放在不同的子进程里执行赋值不会传回父进程。如果你需要在处理中保存中间结果用临时文件或者进程替换( )diff (grep node1 hosts.txt) (grep node2 hosts.txt)这个写法在多文件对比的场景中很舒服(命令)会把命令的输出当成一个虚拟文件传给 diff。重定向这块最基本的三个覆盖写文件、追加、21把标准错误合并到标准输出。21的顺序有讲究command log.txt 21是标准写法如果反过来command 21 log.txtstderr 会跑到终端而不是文件里。原理是重定向按从左到右处理21把 stderr 指到了当前 stdout 的位置后面 stdout 重定向到文件就不影响 stderr 了。这个顺序问题我在帮别人排查脚本时见过好几次值得记牢。丢弃不需要的输出常见写法是/dev/null 21比如前面 ping 的例子运行探测类命令时不希望输出刷屏就把它整个丢进黑洞。6. 常见问题与避坑实录6.1 那些最容易翻车的语法细节把脚本写废的情况大多集中在少数几个细节上。我整理了一张高频坑位表按我见过多少次排的问题现象根本原因正确做法command not found: 变量赋值等号两边有空格去掉空格namexinteger expression expected用-eq比较了非数字字符串字符串比较改用if条件恒真或恒假[ $a$b ]少了空格[ $a $b ]空格不能省文件名被错误拆分for f in $(ls *.log)遇到空格直接用通配符*.logshift count out of rangeshift跳过数量超过剩余参数循环前先判断$#脚本静默失败但继续跑没有set -e加set -euo pipefail变量名拼错没报错未开启set -u空变量被当成空串开启set -u或使用${var:-}回车符导致命令尾部多余字符Windows 编辑保存的 CRLF 换行使用dos2unix转换或用 LF 保存最后一个 CRLF 的问题现在还很常见。很多人用 Windows 上的编辑器写脚本传到 Linux 上一执行就报$\r: command not found。处理办法是执行一次sed -i s/\r$// script.sh或者安装dos2unix批量转换。写脚本工具建议直接选支持 LF 换行的编辑器从源头避免这个问题。还有两个隐蔽坑值得单独说。第一个是通配符没有匹配时的行为for f in *.log当目录下没有.log文件时*.log不会展开成空而是保留字面量*.log循环体就执行了根本没意义的内容。加一句shopt -s nullglob让不匹配的通配符变成空能避免很多莫名其妙的 bug。第二个是while循环里的管道子 shell 问题。如果你写count0 cat file.txt | while read line; do count$((count 1)) done echo $count # 输出 0这里的count不会被累计因为while跑在管道右侧的子 shell 里变量修改传不回父 shell。正确做法是用重定向而不是管道while read line; do ... done file.txt。这个坑的隐蔽性在于脚本不报错结果却是错的很多人排查半天找不到原因。6.2 一份可以直接抄的脚本模板最后给一份我日常写脚本的固定模板你可以直接复制改#!/bin/bash set -euo pipefail # 日志函数信息输出到 stdout错误输出到 stderr log_info() { echo $(date %Y-%m-%d %H:%M:%S) [INFO] $* } log_error() { echo $(date %Y-%m-%d %H:%M:%S) [ERROR] $* 2 } # 默认值 env${ENV:-dev} start_ts$(date %s) if [[ $# -lt 1 ]]; then log_error 缺少参数。用法: $0 {app|db|all} exit 1 fi target$1 case $target in app|db|all) log_info 开始处理 $target, 环境: $env ;; *) log_error 未知目标: $target exit 1 ;; esac # 核心逻辑 for i in {1..3}; do log_info 第 $i 次尝试... # 这里放实际处理命令 break done end_ts$(date %s) log_info 任务完成, 耗时 $((end_ts - start_ts)) 秒模板里包含了set -euo pipefail保证出错即停、日志函数统一输出格式、参数检查和退出码控制。实际业务逻辑直接嵌在case下面就行。这套模板我用了好几年从简单的备份脚本到上百行的部署脚本都是先拿它打底再往里面填业务。6.3 更现代的 Shell 编写习惯写到这顺便说一个提升体验的习惯用shellcheck做静态检查。shellcheck deploy.shshellcheck能查出未引用的变量、set -e的坑、$(ls)之类的危险写法甚至还会给出修改建议。它的定位相当于 Shell 界的代码评审工具。我现在的习惯是脚本写完先跑一遍shellcheck再跑一遍bash -n最后才放到目标机器上执行。前两步加起来可能只需要十几秒但能挡掉前面表格里一半以上的问题。shellcheck支持安装到主流系统上也支持在 VS Code 里做实时提示非常推荐装一个。另外脚本启动时的当前工作目录通常不是你期望的地方尤其是被 cron 调度时pwd可能落在用户家目录。稳妥做法是脚本开头显式cd到脚本所在目录cd $(dirname $0)配合$(dirname $0)拿到脚本路径再配合cd保证后续相对路径都基于脚本目录计算。这个细节对 crontab 任务特别重要我早期吃过不少手动跑没问题、定时跑全挂的亏。如果你在 macOS 上想让这个逻辑更稳可以用${BASH_SOURCE[0]}配合dirname做一层处理不过大部分 Linux 环境下$0已经够用。我个人这几年写 shell 脚本的体会是它的语法体系不复杂但每一条规则背后都藏着 token 切分、子 shell、退出码这类底层机制理解这些机制比背语法重要得多。遇到为什么这样写就不行的问题先拆解一下 shell 是怎么解析这一行的答案往往自己就出来了。这份速查手册把高频场景和踩过的坑都压缩在里面了建议你收藏后按需查阅更建议你在自己的机器上把每个例子敲一遍——代码这种东西动手写过一遍才真正算自己的。比如我这段时间在服务器上清理历史日志从date %Y%m%d生成归档文件名到find ... -mtime 30 -delete清理过期文件整个流程就是在这些基础语法上叠加出来的。你多写几个真实场景的脚本之后会发现这份手册里的大部分条目都会变成肌肉记忆到时候真正需要查的反而是那些一个月才用一次的边角语法。