脚本

变量保存的是一个字符串，但没有引号的展开可能把它变成多个命令参数。Bash 的分词阶段使用 IFS 指定的分隔字符检查展开结果，因此，手动引用后能正常使用的路径，放入变量再传递时却可能突然找不到文件。排查时首先应观察接收命令实际拿到的参数数量和每个参数的内容，也要区分空字符串与完全没有参数，不能仅凭终端上看起来相同的一行文本判断输入一致。 IFS 控制分词，而引用还能阻止文件名展开。空参数和没有参数仍是不同情况。 是否分词取决于上下文 默认 IFS 包含空格、制表符和换行符，它们的连续组合会分隔字段，开头和结尾的这类空白也会被忽略。未引用变量里有两个单词时，命令通常收到两个参数；变量为空时，则通常连一个参数都没有。使用 "$value" 会保留一个参数，即使值是空字符串。对于命令行接口，显式传入空值和省略选项值可能触发完全不同的行为。 分词针对适用上下文中的未引用参数展开、命令替换和算术展开结果，并不是重新解析整条命令。普通赋值语句 copy=$value 会保留原字符串，不执行分词和文件名展开。但随后把 $copy 不加引号地作为命令参数使用，仍会重新引入两个问题。Bash 双方括号条件表达式也具有不同于普通命令参数的展开规则，所以赋值或条件判断成功，不能证明后面的外部程序调用也安全。 IFS 是一组分隔字符，不是多字符分隔串，也不是正则表达式。非空白分隔符和空白的处理并不相同，例如连续两个冒号可以产生一个空字段，而连续默认空白通常只是一个字段边界。把 IFS 设为空字符串会关闭分词，但不会把未引用的空展开变成显式空参数。若数据格式有引号、转义或嵌套结构，应使用理解该格式的解析器，不能把调整 IFS 当作通用解析方法。 坏掉的样子 关闭分词并没有关闭随后的文件名展开。即使 IFS 为空，变量里的星号仍可能匹配当前目录下的文件；目录里刚增加一个文件，同一条命令的参数数量就会改变。引用变量能够同时阻止这两种转换，而修改 IFS 只处理了其中一个阶段。控制通配符的 shell 选项也独立存在，不能把它们和分词配置混为一谈。 ...

Shell 脚本接收的是有顺序的参数列表，不是需要重新按空格拆分的一整条命令字符串。位置参数通过 $1、$2 等编号暴露这份列表，$# 表示数量。固定且简单的接口可以直接使用位置，带可选设置或开关的接口则适合明确解析。无论采用哪种形式，都需要规定允许几个参数、是否允许空值，以及输入错误时怎样失败。 先保留参数列表，再解释含义。语法解析与业务验证是两道独立检查；重复调用需要新的局部解析状态。此图表示原文实验预期，本轮未重新执行。 解释含义之前，先保住列表边界 $0 表示脚本名称等特殊身份，不属于位置参数，也不计入 $#。使用 bash -c 时，命令字符串之后的第一个参数会成为 $0，包装脚本若误以为它是 $1，就会看起来少收到一个参数。超过第九个位置必须使用花括号：${10} 是第十个参数，$10 却是第一个参数再接一个字面数字零，两种写法不能互换。 "$@" 会为每个传入参数保留一个词，包括空字符串和包含空格的值。未引用的展开可能再次分词并展开通配符，"$*" 则会把列表连成一个字符串。转发或遍历时应使用带引号的完整列表。set -- 替换当前的位置参数，shift 删除前面的若干项；这些操作在对应脚本或函数作用域中生效，不会反向改写外部调用者原来的参数列表。 空参数仍然占据一个位置。检查 $# 可以区分完全没有提供参数，与明确传入 '' 两种情况。${1:?message} 同时拒绝缺失和空值，只有接口要求非空时才合适。应先验证数量，再读取必需的位置，最后判断内容是否合法，避免在参数本来不存在时就触发与接口说明无关的展开错误。 ...

参数展开根据 Shell 参数产生一个值，随后命令才收到展开后的参数。它可以提供默认值、拒绝缺失配置，或者删除字符串的一部分，不必为这些操作启动额外进程。但“执行命令前展开”并不等于“初次解析脚本时就求值”：函数在被调用时读取变量当前的内容，函数定义之后修改变量，会影响后续调用。区分解析、展开和执行，才能解释为什么相同的表达式在不同时间产生不同结果。 冒号把空字符串也计入缺值条件。普通默认值不改保存状态，赋值默认值会回写。Shell 模式删除改变结果，不改原变量，也不访问文件系统。 默认值要区分未设置与空字符串 ${setting:-default} 在变量未设置或者为空时使用默认值；${setting-default} 只处理未设置的情况，保留调用者明确传入的空字符串。冒号改变的是配置语义，不能当成随意省略的标点。例如空字符串可能表示关闭某个前缀，擅自用默认值替换就会改变用户的选择。${setting:+enabled} 只在变量已设置且非空时产生替代文本，去掉冒号后，已设置但为空也满足条件。 普通默认值展开不会修改变量本身。${setting:=default} 才会在选中默认分支时把结果存进变量，之后再读取就能看到新值。${setting:?message} 则在变量未设置或为空时把诊断写到标准错误，并让非交互 Shell 以非零状态退出。去掉冒号后，这两个运算符也只检查是否设置。应当先确定调用约定：允许为空、允许省略，还是必须提供，然后选择相应形式，而不是把所有配置问题都掩盖成一个默认值。 花括号还负责把变量名与相邻文本分开。"${prefix}_suffix" 是给变量内容追加后缀，"$prefix_suffix" 却读取另一个变量。用几个配置拼文件名时，看似缺值的问题可能只是变量名边界写错。应分别检查各个组成部分，再排查最终路径；一个语法完全合法的字符串，也可能混入来自错误变量的内容。 模式处理字符串，不访问文件 ${name#pattern} 与 ${name##pattern} 分别删除最短和最长匹配前缀；对应的后缀运算符是 % 与 %%。这里使用 Shell 模式，不是正则表达式。匹配不到时保留原字符串，匹配成功也不会自动回写原变量。斜杠在这里就是普通的文本内容，这些运算不会查询目录、确认文件存在或者解析符号链接，因此不能用一次字符串截取证明路径安全。 ...

Bash 命令中的通配符通常会在目标程序启动前变成一组路径。它让批量处理很方便，也让同一行命令受到当前目录和 shell 选项的影响。程序拿到的是已经形成的参数，不会收到标记来告诉它哪些参数来自星号。因此，写命令时应先确定：希望传入实际匹配的文件，还是希望把模式本身交给另一个程序解释。两者需要不同的引号写法，不能依靠目标程序猜测意图。 文件名展开保留各个匹配项内的空格。未匹配策略和接收程序的语义仍需分别处理。 先匹配，再保留参数边界 Bash 先进行分词，再进行文件名展开。没有引用的星号、问号和方括号模式可能因此生成多个参数。但匹配到的文件名即使包含空格，也仍然是一个参数，因为文件名展开之后不会再执行一次分词。常见问题发生在下一步：循环拿到了完整路径，却用没有引号的变量把它传给另一个命令。循环体中的 "$file" 仍然必要，不能因为前一步通配成功就省掉。 如果接收方需要模式，就应引用模式。例如 find . -name '*.txt' 将匹配规则交给 find；去掉引号后，Bash 会先在当前目录展开它，find 得到的可能是多个文件名，已经不是原来要表达的条件。变量里包含星号时也一样：引用变量会传递字面星号，不引用则可能触发文件名展开。引号只控制当前 shell 如何形成参数，不会禁止接收方按自己的语法解释收到的文本。 通配符匹配目录项，并不保证结果都是普通文件。名为 archive.txt 的目录也能匹配 *.txt，只想处理普通文件时还需要判断类型。普通星号不会越过斜杠，默认也不匹配名字开头的点；需要隐藏文件时，应明确使用相应模式或开启 dotglob。遍历整棵目录树是另一个需求，不能把当前目录的一次展开误认为递归搜索。 环境变量也能改变结果集合。Bash 中非空的 GLOBIGNORE 会过滤匹配结果，并且产生开启 dotglob 的副作用。因此，从交互会话继承状态的脚本可能意外纳入隐藏文件。下面的实验会清除 GLOBIGNORE 及较新版本的排序覆盖变量 GLOBSORT，并明确指定相关选项，让断言对应一套可重复的环境，而不是依赖读者终端的偶然配置。 ...

包装脚本应当把收到的参数按原有边界继续传递。在 Bash 的命令参数位置，"$@" 会让每个位置参数分别成为一个带引号的词，因此能保留空值、空格、换行和字面通配符。只用两个简单文件名测试成功，并不能证明包装脚本正确；一旦它把参数列表拼成字符串再拆开，真实调用者传入的边界就可能丢失。转发是否可靠，应当用能暴露这种差异的输入来验证。 应转发列表本身。引号保留参数边界，但不决定下游选项解析，也不会让其他 shell 状态自动局部化。 参数列表与拼接文本不同 位置参数属于当前脚本或正在执行的函数。$# 返回参数数量，内容为空字符串的参数也计算在内。"$1" 读取第一个参数，"${10}" 读取第十个；后者需要花括号，以区别于第一个参数后面接字符零的写法。$0 表示启动的 shell 或脚本名称，不会作为额外元素出现在 "$@" 中，不能把它误算进业务参数列表。 在普通命令边界上，"$@" 为每个参数保留一个独立词；完全没有位置参数时，它不产生任何参数。相比之下，"$*" 始终形成一个字符串，用 IFS 的第一个字符连接各个值。IFS 未设置时使用空格，设为空字符串时则不插入分隔符。它并不会删除参数内部原有的空格，但各参数原来的边界通常已经无法恢复，因此不适合转发任意列表。 省略引号的 $@ 不是等价简写，展开后的内容仍可能被分词和文件名展开处理。调用者传入的字面星号，到了包装脚本所在目录可能突然匹配出一组文件。往拼接文本里补引号字符也不能恢复结构。需要把列表保存到之后使用时，在 Bash 中写成 args=("$@")，并通过 "${args[@]}" 转发，即使随后调整位置参数，保存的列表仍保留各个元素。 坏掉的样子 函数执行期间拥有自己的位置参数列表。调用时传入的参数暂时替换当前可见列表，返回时恢复调用者的列表。函数内部使用 set 或 shift 修改的是这次函数调用的参数，但这不代表其他所有 shell 状态都自动局部化。例如，没有局部声明就修改 IFS，可能影响调用者之后的命令。参数作用域和普通变量作用域应分别理解，不能互相推导。 ...

退出状态是 shell 用来决定下一步执行什么的小整数。对 shell 控制流来说，零表示成功，非零进入失败分支，但这并不意味着每个数字都有统一的业务含义。搜索没有匹配、输入格式错误和服务器不可用，都可能返回非零，却需要不同处理。决定重试、忽略或终止之前，应先阅读目标命令的契约。不能只因为状态不为零，就把所有结果归为同一种事故。 趁状态仍对应目标命令时立即保存。日志、控制流变换和后台完成检查之后，仍需保留并传播正确结果。 让状态始终对应原来的命令 Bash 通过 $? 提供最近前台命令的状态。需要保留时，必须在记录日志、执行另一个条件判断或清理操作之前保存；这些操作也有自己的状态，会覆盖原本想观察的证据。函数通常使用最后执行的命令状态作为返回值，因此，末尾一句成功的日志输出就可能把前面的失败包装成整个函数成功，调用者看到的结果与实际工作脱节。 ...

Shell 函数把一组命令组织到同一个名称之下，并接收本次调用自己的位置参数。普通调用时，函数体在当前 Shell 中执行，不会自动启动独立进程。这方便复用操作，也意味着赋值、切换目录及其他 Shell 状态变化可能影响调用方。函数接口除了规定输入，还应明确输出、退出状态和有意产生的副作用，不能只因为把几行命令包进了函数，就认为它们已经与外层隔离。 普通函数调用共享 Shell。返回时恢复位置参数帧，但嵌套辅助函数仍能修改动态局部绑定；数据和失败状态需要分别约定。此图表示原文实验预期，本轮未重新执行。 每次调用都有自己的参数列表 调用 demo_func first second 后，这次函数内部的前两个位置分别是传入的两个值，参数数量为二。再次调用其他函数，会暂时安装下一层自己的参数列表；返回后，调用者的列表重新可见。因此，在被调用函数中移位，不会消耗调用者的位置参数。Bash 的 $0 也不会因此变成当前函数名称，不能用它判断自己正在哪个函数里面。 使用 "$@" 转发整份列表，才能保留空参数、空格以及通配符字符各自的边界。应先检查数量，再读取必需的位置，同时区分省略参数与明确传入空字符串。Shell 函数没有自动执行这些规则的参数声明，调用时语法上能写出一串值，并不意味着这些值已经满足函数的业务约定。 局部变量使用动态作用域 Bash 的局部声明会创建一个变量，遮住外层的同名绑定；函数返回之后，原来的绑定再次可见。若修改调用者变量并不是接口的一部分，应为临时值、循环计数器等声明局部变量。面向多个解释器的可移植脚本，不能假设每个 Shell 都实现了 Bash 的这套局部变量设施，解释器要求必须与使用的语法保持一致。 ...

命令替换会收集一个命令的标准输出，再把得到的文本放入外层表达式。常见的 $(command) 适合获取时间戳、计算出的标签或其他较小的文本值，但它并不是任意字节的透明传输通道，也不是可靠的文件名列表容器。使用前需要理解三个边界：末尾换行如何处理、内部命令在哪个执行环境运行，以及失败状态如何传递。只看到变量里有内容，不能证明整个操作成功。 捕获文本与退出状态走不同路径。引号保留结果参数，不能恢复已删除的换行。标准 $(...) 隔离 Shell 状态，却不会撤销外部副作用。此图表示原文实验预期，本轮未重新执行。 先收集文本，再决定怎样使用 本文讨论的标准命令替换形式会让 Bash 在子 shell 环境中运行内部命令，收集标准输出，并删除末尾所有换行符。位于文本中间的换行仍然保留。双引号能阻止后续分词和文件名展开，却不能恢复已经删除的尾部换行。如果需要精确保留最后几个字节，应该使用文件或数据流，而不是依靠 shell 变量原样往返。 赋值语句 result=$(producer) 会把处理后的文本存进变量，不在此处拆成多个参数。后续使用时仍应写成 "$result"，保留它的参数边界。类似地，consumer "$(producer)" 会传递一个参数，即使结果为空。去掉引号可能得到多个参数，也可能完全没有参数；输出中的星号还可能匹配当前目录的文件，让同样的生产者输出在不同目录产生不同调用结果。 标准错误和标准输出彼此独立，除非主动重定向，诊断信息仍可能显示在终端，而变量只收集结果正文。将两路输出合并后，警告文本可能污染本应供程序读取的值。因此，应先确定生产者的输出契约，再决定是否合并；直接吞掉所有诊断信息也可能让空结果失去可解释的原因。输出内容、诊断信息和退出状态应分别检查。 不要把这里的作用域结论推广到较新 Bash 的每一种捕获语法。本文使用的美元符号加圆括号形式具有实验验证的子 Shell 行为；较新的当前环境捕获形式会保留不同的副作用。说明一个捕获值时，应明确语法与解释器版本，而不是把所有能够取得文本的写法都视为等价。 ...