1. 为什么每个运维人最后都得回头补上Shell变量这一课刚入行那会儿我对Shell脚本的态度特别矛盾。一方面觉得它土语法古怪连个像样的类型系统都没有另一方面又不得不承认每次服务器上出点状况最后能救命的往往就是几行临时敲出来的Shell命令。后来带过几个新人发现一个特别普遍的现象很多人能照着网上的教程写出for循环能跑通if判断但一旦脚本稍微复杂一点变量赋值出了岔子字符串拼接莫名其妙多了空格整个人就卡住了。问题的根子不在逻辑在于对变量和字符串这两块地基没打牢。Shell里的变量跟Python、Java完全不是一回事它没有类型声明没有作用域关键字赋值时等号两边不能有空格这种反直觉的规则字符串拼接直接往一起写就行取变量值要加$但有时候又不用加。这些细节单独拎出来都不难可它们凑在一起就成了新手写脚本时踩坑最密集的区域。这篇内容就是冲着这个来的。我会把Shell变量和字符串的用法从头到尾捋一遍重点讲清楚那些教程里经常一笔带过、但实际写脚本时天天遇到的东西变量什么时候该加引号、$*和$到底差在哪、字符串截取和替换的几种写法怎么选、命令替换用反引号还是$()。适合已经能写简单脚本、但总觉得变量这块用得不踏实的读者也适合完全从零开始、想一次性把基础打好的朋友。2. Shell变量的本质没有类型但有规矩2.1 变量赋值那条“等号两边不能有空格”的铁律先看一段代码你猜哪个能跑name server01 nameserver01第一个直接报错name: command not found。原因在于Shell把空格当作命令和参数的分隔符name server01会被解析成“执行一个叫name的命令参数是和server01”。Shell根本不认识name这个命令所以报错。第二个才是正确的赋值语法。这条规则几乎每个Shell新手都会踩一次而且踩完之后容易形成肌肉记忆反而在写其他语言时也习惯性地在等号两边不加空格搞得代码风格很别扭。我的建议是写Shell的时候脑子里明确切换一个模式赋值就是“变量名值”中间不留任何空白。如果值里面本身包含空格必须用引号包起来greetinghello world不加引号的话Shell会把hello赋给greeting然后试图把world当作一个命令去执行又是一轮报错。2.2 变量引用什么时候必须加花括号取值用$符号这个大家都知道。但什么时候该写成${name}什么时候$name就够了很多人是凭感觉来的。看这个场景prefixlog echo $prefix_file你以为会输出log_file实际上Shell会去找一个叫prefix_file的变量找不到就输出空。正确写法是${prefix}_file。花括号的作用是明确变量名的边界告诉Shell变量名到哪里结束。我的习惯是只要变量后面紧跟着字母、数字或下划线一律用${}包起来。这样不用每次去纠结边界问题代码可读性也更好。只有在变量后面跟的是空格、标点或者字符串结尾时才偷懒用$name。2.3 单引号、双引号、反引号三种引号的分工Shell里的引号是新手最容易混淆的地方我把它拆成三种情况来说。单引号是“所见即所得”里面的一切都是普通字符变量不会被展开nameworld echo hello $name # 输出 hello $name echo hello $name # 输出 hello world双引号允许变量展开和命令替换但会保留空格等特殊字符的字面意义。这是日常写脚本时用得最多的引号形式。反引号用于命令替换把命令的输出结果赋给变量todaydate %Y-%m-%d但反引号有个致命缺点嵌套困难而且视觉上容易和单引号混淆。现在推荐一律用$()代替today$(date %Y-%m-%d) files$(ls -1 | wc -l)$()支持嵌套可读性也好得多。我在code review时看到反引号基本都会建议改成$()。2.4 环境变量、局部变量与export的那道墙Shell变量按作用范围分几种。直接在脚本里赋值的是普通变量只在当前Shell进程里有效。子进程看不到父进程的普通变量除非用export导出成环境变量。myvarhello export myvar bash -c echo $myvar # 输出 hello如果不export子Shell里echo $myvar就是空的。这个机制在写多脚本协作的时候特别重要。比如你写了一个主脚本调用另一个子脚本主脚本里定义的配置变量如果不export子脚本根本读不到。在函数内部可以用local声明局部变量避免污染全局myfunc() { local tmptemp value echo $tmp }不加local的话函数里赋值的变量默认是全局的函数执行完还留在环境里容易造成变量名冲突。这个坑我在维护老脚本时遇到过好几次两个函数用了同一个临时变量名互相覆盖排查了半天。3. 字符串操作Shell里最被低估的一套工具3.1 字符串长度、截取与位置查找Shell内置了一套字符串处理语法不用调用awk或sed就能完成大部分常见操作。先看长度strhello world echo ${#str} # 输出 11${#变量名}返回字符个数注意是字符数不是字节数中文环境下要留意编码问题。截取用${变量:起始位置:长度}strabcdefghij echo ${str:2:3} # 输出 cde echo ${str:5} # 输出 fghij起始位置从0开始算。省略长度就截到末尾。这个语法在处理文件路径、日志行的时候特别顺手。查找子串位置没有内置语法得借助expr indexexpr index $str d # 输出 4注意expr index返回的是1-based的位置跟大多数编程语言从0开始不一样用的时候要换算。3.2 字符串替换的四种模式替换是字符串操作里用得最频繁的。Shell提供了四种替换模式区别在于“替换第一个”还是“替换全部”以及“从前面匹配”还是“从后面匹配”。语法作用${str/old/new}替换第一个匹配${str//old/new}替换全部匹配${str/#old/new}只替换开头的匹配${str/%old/new}只替换结尾的匹配举个例子path/home/user/docs/file.txt echo ${path//\//_} # 输出 _home_user_docs_file.txt这里把所有的斜杠替换成下划线注意斜杠在替换语法里需要转义。这个技巧在生成文件名、构造日志标签时很实用。再比如去掉文件扩展名filenamereport.pdf echo ${filename%.*} # 输出 report%.*表示从结尾开始匹配最短的.*模式也就是最后一个点及其后面的内容。如果要匹配最长的用%%.*。3.3 大小写转换与去空白Bash 4.0以上支持大小写转换strHello World echo ${str,,} # 输出 hello world echo ${str^^} # 输出 HELLO WORLD,,转小写^^转大写。单个逗号或尖号只转换第一个字符。去空白没有内置语法通常用xargs或者参数扩展配合sedtrimmed$(echo hello | xargs)xargs默认会去掉首尾空白并把内部连续空白压缩成单个空格。如果只想单纯去首尾空白用sed更精确trimmed$(echo hello | sed s/^[[:space:]]*//;s/[[:space:]]*$//)3.4 字符串比较、和-z的适用场景字符串比较在条件判断里用得很多但语法细节容易搞混。在[ ]里比较字符串用或if [ $a $b ]; then echo equal fi注意变量一定要加双引号否则变量为空时[ $b ]会报语法错误。这是Shell脚本里最经典的坑之一。判断字符串是否为空用-z非空用-nif [ -z $str ]; then echo empty fi在[[ ]]里可以用做模式匹配if [[ $filename *.txt ]]; then echo text file fi[[ ]]是Bash的扩展语法比[ ]更安全支持正则和模式匹配推荐在Bash脚本里优先使用。4. 那些让脚本突然崩掉的变量陷阱4.1 未定义变量与set -u的取舍Shell默认对未定义变量很宽容引用一个不存在的变量只会得到空字符串不会报错。这在简单脚本里无所谓但在复杂脚本里是灾难——变量名拼错了脚本继续跑结果全错你还不知道问题出在哪。set -u可以让Shell在引用未定义变量时直接报错退出set -u echo $undefined_var # 报错undefined_var: unbound variable我现在的习惯是每个正式脚本开头都写set -euo pipefail分别对应遇错退出、未定义变量报错、管道中任一命令失败就整体失败。这三条能挡掉大量隐蔽bug。但set -u有个副作用$1、$2这类位置参数如果没传也会触发报错。这时候可以用默认值语法兜底name${1:-default}:-表示如果变量未定义或为空就用后面的默认值。4.2 命令替换中的换行与空格丢失命令替换$(...)会把输出末尾的换行符去掉但中间的换行会保留。如果直接不加引号使用Shell会做单词拆分把换行和空格都当作分隔符files$(ls) echo $files # 所有文件名挤在一行 echo $files # 保留原始换行这个差异在处理文件名列表时特别关键。不加引号的话带空格的文件名会被拆成多个词后续处理全乱套。我的原则是命令替换的结果只要不是明确要拆分的一律加双引号。4.3$*和$一个引号引发的血案这两个特殊变量都表示所有位置参数但不加引号时行为一样加了引号就分道扬镳set -- a b c d echo $* # 输出 a b c d作为一个整体 echo $ # 输出 a b 和 c d两个独立参数$*把所有参数拼成一个字符串$保持每个参数的独立性。写函数转发参数时几乎总是应该用$myfunc() { other_func $ }用$*的话原本带空格的参数会被合并接收方拿到的参数结构就变了。这个坑我在写部署脚本时踩过传路径参数带空格结果目标脚本收到的参数数量不对排查了很久。4.4 变量名冲突与作用域污染前面提过local的重要性这里再展开说一个实际场景。假设你写了一个工具脚本里面定义了一个tmp变量存临时目录。后来这个脚本被source到另一个脚本里使用而外层脚本也用了tmp变量两边就打架了。# outer.sh tmp/outer/tmp source inner.sh echo $tmp # 可能已经被inner.sh改掉了解决办法有两个一是函数内一律用local二是给变量加前缀比如MYTOOL_tmp。我倾向于两者结合函数内用local全局变量加项目前缀最大限度避免冲突。5. 从零写一个字符串处理脚本完整实操5.1 需求拆解与设计思路假设我们要写一个脚本处理一批日志文件名完成以下任务提取日期、判断是否为错误日志、生成对应的归档目录名。日志文件名格式类似app_20240315_error.log。设计思路用参数扩展提取各部分用模式匹配判断类型用字符串拼接生成新名字。整个脚本不依赖awk、sed等外部命令纯Bash内置语法完成这样执行效率高也不受环境差异影响。5.2 逐段实现与关键注释#!/bin/bash set -euo pipefail process_log() { local filename$1 local basename${filename##*/} local name_no_ext${basename%.log} local date_part${name_no_ext#app_} date_part${date_part%%_*} local type_part${name_no_ext##*_} local archive_dirarchive/${date_part} if [[ $type_part error ]]; then archive_dir${archive_dir}/errors else archive_dir${archive_dir}/normal fi echo 文件: $filename - 归档目录: $archive_dir } for f in $; do process_log $f done逐段解释关键点。${filename##*/}去掉路径部分只留文件名##表示从前面匹配最长模式。${basename%.log}去掉.log后缀%表示从后面匹配最短模式。${name_no_ext#app_}去掉开头的app_#表示从前面匹配最短模式。${date_part%%_*}从第一个下划线处截断%%表示从后面匹配最长模式。这几个符号#、##、%、%%的记忆方法是#在键盘上在$左边对应“前面”%在$右边对应“后面”。单个符号是“最短匹配”双符号是“最长匹配”。5.3 测试用例与边界情况拿几个文件名跑一下./process.sh app_20240315_error.log app_20240316_info.log输出文件: app_20240315_error.log - 归档目录: archive/20240315/errors 文件: app_20240316_info.log - 归档目录: archive/20240316/normal边界情况要考虑文件名不含下划线怎么办${date_part%%_*}会返回整个字符串不会报错但结果不对。文件名不以app_开头怎么办${name_no_ext#app_}会原样返回也不会报错。这些情况需要在调用前做校验或者用[[ ]]做模式匹配判断。我在实际使用中会加一层校验if [[ ! $basename ~ ^app_[0-9]{8}_(error|info)\.log$ ]]; then echo 跳过不识别的文件: $filename 2 return fi用正则做严格匹配不符合格式的直接跳过避免产生错误的归档目录。6. 调试变量问题的几个实用手段6.1set -x与PS4定制脚本跑出来的结果不对第一反应应该是打开跟踪。set -x会把每条执行的命令打印出来变量会被展开成实际值set -x nameworld echo hello $name输出 nameworld echo hello world hello world行首的是默认的提示符可以通过PS4变量定制加上行号和函数名export PS4${BASH_SOURCE}:${LINENO}:${FUNCNAME[0]}: 这样每行跟踪信息都会带上文件名、行号和函数名排查复杂脚本时定位快很多。6.2 用declare -p查看变量真实状态有时候变量值看起来对但比较就是不相等多半是藏了不可见字符。用declare -p可以看到变量的完整定义strhello declare -p str # 输出 declare -- strhello如果值里有尾随空格或换行这里会暴露出来。另一个办法是用printf配合%qprintf %q\n $str%q会把特殊字符转义显示空格、换行、制表符都无所遁形。6.3 常见报错信息对照表报错信息原因解决command not found赋值时等号两边有空格去掉空格unbound variable引用了未定义变量且开了set -u用${var:-default}兜底bad substitution用了不支持的参数扩展语法检查Shell版本确认是Bashtoo many arguments[ ]里变量没加引号且为空加双引号syntax error near unexpected token引号不匹配或缺少fi、done检查配对这张表里的前四条基本覆盖了我这些年遇到的大部分变量相关报错。特别是too many arguments十有八九是[ $var x ]这种写法变量为空时变成[ x ][命令收到两个参数就懵了。7. 我踩过的那些变量坑与个人习惯说几个印象深刻的。有一次写批量重命名脚本用for f in $(ls)遍历文件测试时用的都是简单文件名跑得好好的。上线后遇到一个文件名带空格整个逻辑就崩了因为$(ls)的输出被单词拆分了。后来改成for f in *或者find ... -print0 | while IFS read -r -d 才彻底解决。这个教训让我记住了永远不要用$(ls)做遍历。还有一次脚本里用read读配置文件值里带了反斜杠结果被read吃掉了。read默认会把反斜杠当作转义符加-r参数才能原样读取。现在我的习惯是read一律加-r除非明确需要转义处理。关于变量命名我现在的个人规范是环境变量全大写加下划线脚本内部变量全小写加下划线函数内临时变量加local全局配置变量加项目前缀。这套规范没什么技术含量但能省掉大量“这个变量哪来的”的困惑。最后分享一个提高脚本健壮性的小技巧在脚本开头加一段参数校验用${var:?error message}语法变量未设置时直接报错退出并打印提示: ${CONFIG_FILE:?必须设置CONFIG_FILE环境变量}这行代码在变量未定义时会输出必须设置CONFIG_FILE环境变量并退出比等到后面用到时才报错要清晰得多。这个写法在写需要外部传参的脚本时特别有用相当于给变量加了一道前置检查。