Shell · XB 现场笔记

bash history 是可以搜索的命令日志

Mon, 28 Feb 2028 00:00:00 +0000

命令历史能减少重复输入，却不是所有已执行操作的完整记录。Bash 通常在交互 Shell 中启用历史功能，配置还可以过滤条目或限制保留数量。运行中 Shell 的可搜索列表，与磁盘上的历史文件，是两个独立状态。理解这个区别，才能解释为什么某条命令在一个终端能找到，在另一个终端却没有，以及为什么意外结束会话可能丢掉尚未保存的记录。

会话内存与历史文件不同

HISTSIZE 限制内存中的历史条目数量，HISTFILESIZE 限制保存文件的行数。多行命令与时间戳记录会让行数不等于命令数，不能用简单的文件行数判断究竟保留了多少次操作。HISTFILE 决定保存位置，通常指向用户的 Bash 历史文件。变量未设置或为空时不会正常保存；目标不可写时，当前会话仍可能查到记录，却没有对应的持久化副本。

Bash 在参数展开之前、历史展开之后记录命令文本，并受到 HISTCONTROL 与 HISTIGNORE 的影响。因此，保存下来的变量引用并不一定显示原来执行时的变量值。当前目录、别名、函数、环境及外部文件，也都可能在下次复用命令之前发生变化。历史保存的是有用的输入，不是完整的可复现运行环境，更不是可以直接信任的操作审计证据。

追加保存不会自动刷新其他终端

Bash 正常退出时保存历史，histappend 决定追加到文件还是覆盖文件。如果此前没有主动保存，异常终止可能丢掉全部未写入的条目，不只是最后一条。history -a 追加当前会话新输入、且尚未追加过的历史行。提前保存可以缩小丢失窗口，但不等于承诺任何系统故障之后都能完整恢复，更不能把一次文件写入等同于业务日志的可靠持久化。

另一个仍在运行的 Shell 持有自己的列表，需要通过 history -n 等操作读取新追加的行。仅仅启用追加选项，不会让另一个终端的搜索结果实时更新。history -r 把整个文件内容追加到现有列表，重复运行可能制造重复条目；history -w 则用当前列表替换文件，可能丢掉其他会话留下的记录。这些命令的方向和覆盖语义不同，不能当作几种等价的同步写法。

如果把追加和导入接入 PROMPT_COMMAND，还要保留已有提示符钩子，以及它们对上一条命令退出状态的使用。直接覆盖已有钩子可能破坏其他 Shell 行为。多个会话共享一个文件，也不会因此形成可信的全局执行顺序。需要顺序、退出码或责任归属时，应使用独立的操作日志，而不是从交错的历史文本中反推完整事实。

搜索后先检查，再执行

在常见的 Emacs 风格 Readline 绑定中，Ctrl-R 向后增量搜索，再按一次查找更早的匹配。应使用编辑按键退出搜索，先检查所选命令，再决定是否执行；Ctrl-G 可以取消搜索。回车会接受命令，Ctrl-J 也是换行，不能把它说成不会执行的预览键。其他编辑模式或自定义终端的绑定可能不同，应以当前配置为准。

复用旧命令时，检查主机名、目录、选项和目标。上个月正确的命令，今天可能已经指向另一套环境。用辨识度高的片段搜索可以减少翻找，但找到之后仍应查看整行，不能把第一条匹配结果直接当成当前想做的操作。历史搜索解决的是找回输入的问题，不负责重新判断操作意图。

坏掉的样子

命令消失可能来自过滤规则、保留上限、不同的历史文件、保存失败，或者当前会话没有导入新记录。应分别核对这些原因。ignoredups 只排除连续重复，不会对整个历史全局去重；ignoreboth 只是把它与忽略行首空格的规则组合，也不会得到一份全局唯一的命令档案。判断条目是否丢失之前，先明确当前启用了什么过滤条件。

行首空格只有在相应配置生效时才会排除条目。它不会移除终端录制、进程参数或其他位置的日志，因此不能把凭据直接放进命令行，再依赖历史过滤保证保密。诊断示例也应使用合成条目和临时历史文件，避免为了证明历史功能可用，就把真实用户最近执行过的命令打印出来。

快速验证

使用 Python 3、Bash 和常见 Unix 工具运行下面的完整示例。环境在 Bash 启动之前就把历史文件指向临时目录，整个过程只查看合成文本。花括号分组让控制命令先被整体读取，避免启用历史之后又把实验自身的控制步骤逐行写进列表。退出前解除自动保存目标，随后由临时目录管理器清理测试文件。

import os
import subprocess
import tempfile
from pathlib import Path

script = r'''{
set -eu
set -o history
history -c
history -s 'demo original'
history -w "$HISTFILE"
printf 'first-file:\n'
cat "$HISTFILE"
history -c
history -s 'demo replacement'
history -w "$HISTFILE"
printf 'replacement-file:\n'
cat "$HISTFILE"
history -r "$HISTFILE"
printf 'memory-after-reread:\n'
history | sed 's/^[[:space:]]*[0-9][0-9]*[[:space:]]*//'
unset HISTFILE
}'''
with tempfile.TemporaryDirectory(prefix="bash-history-demo-") as directory:
 history_path = Path(directory) / "history"
 env = dict(os.environ, BASH_ENV="", HISTFILE=str(history_path), HISTSIZE="100",
 HISTFILESIZE="100", HISTCONTROL="", HISTIGNORE="",
 HISTTIMEFORMAT="")
 subprocess.run(["bash", "--noprofile", "--norc", "-c", script],
 env=env, check=True)

第一次写入后，文件只包含 demo original；替换后只包含 demo replacement。内存已经有替换条目，再读取文件，会看到两条相同内容。这组结果直接区分覆盖文件与向内存追加，并且不会执行保存的那些字符串。它没有把文件操作试验冒充键盘绑定验证或崩溃持久性测试；后两者需要在对应环境中单独观察。

来源

Bash 历史设施，会话列表与历史文件的保存规则，已核验 2026-09-07。
Bash 历史内建命令，追加、替换及导入条目的差异，已核验 2026-09-07。
Readline 历史命令，搜索及接受命令的按键绑定，已核验 2026-09-07。

Shell 的字段拆分把未加引号的变量拆成多个参数

Fri, 31 Dec 2027 00:00:00 +0000

变量保存的是一个字符串，但没有引号的展开可能把它变成多个命令参数。Bash 的分词阶段使用 IFS 指定的分隔字符检查展开结果，因此，手动引用后能正常使用的路径，放入变量再传递时却可能突然找不到文件。排查时首先应观察接收命令实际拿到的参数数量和每个参数的内容，也要区分空字符串与完全没有参数，不能仅凭终端上看起来相同的一行文本判断输入一致。

是否分词取决于上下文

默认 IFS 包含空格、制表符和换行符，它们的连续组合会分隔字段，开头和结尾的这类空白也会被忽略。未引用变量里有两个单词时，命令通常收到两个参数；变量为空时，则通常连一个参数都没有。使用 "$value" 会保留一个参数，即使值是空字符串。对于命令行接口，显式传入空值和省略选项值可能触发完全不同的行为。

分词针对适用上下文中的未引用参数展开、命令替换和算术展开结果，并不是重新解析整条命令。普通赋值语句 copy=$value 会保留原字符串，不执行分词和文件名展开。但随后把 $copy 不加引号地作为命令参数使用，仍会重新引入两个问题。Bash 双方括号条件表达式也具有不同于普通命令参数的展开规则，所以赋值或条件判断成功，不能证明后面的外部程序调用也安全。

IFS 是一组分隔字符，不是多字符分隔串，也不是正则表达式。非空白分隔符和空白的处理并不相同，例如连续两个冒号可以产生一个空字段，而连续默认空白通常只是一个字段边界。把 IFS 设为空字符串会关闭分词，但不会把未引用的空展开变成显式空参数。若数据格式有引号、转义或嵌套结构，应使用理解该格式的解析器，不能把调整 IFS 当作通用解析方法。

坏掉的样子

关闭分词并没有关闭随后的文件名展开。即使 IFS 为空，变量里的星号仍可能匹配当前目录下的文件；目录里刚增加一个文件，同一条命令的参数数量就会改变。引用变量能够同时阻止这两种转换，而修改 IFS 只处理了其中一个阶段。控制通配符的 shell 选项也独立存在，不能把它们和分词配置混为一谈。

另一个常见问题是用一个字符串保存整组参数，然后往字符串内部塞引号。Bash 不会在变量展开后把这些字符重新当作 shell 源码里的引号，因此它们不能恢复原有参数边界。不要用 eval 补救：它会增加一次 shell 解析，让原本的数据获得执行命令的机会。需要在 Bash 中逐步组装命令时，使用数组保存各项，并通过 "${args[@]}" 传递，每项内容和空值都能独立保留。

有些协议确实规定了分隔符，此时主动分词可以合理使用，但必须先明确格式、空字段含义和有效字符范围，并把 IFS 的修改限制在所需操作范围。任意文件名和带引号的逗号分隔记录都不适合直接按空白切开。本文实验明确使用 Bash；其他 shell 的默认行为可能不同，例如通常配置下的 zsh 不会以相同方式拆分普通标量展开，不能把一个终端的观察直接推广到所有 shell。

例如，变量展开产生的分号不会自动升级为 shell 的命令分隔符。它仍然属于参数数据，尽管周围文本仍可能被分词破坏。参数构造错误与主动把字符串重新解释成代码是两个不同问题，修复时应定位实际发生转换的阶段。

快速验证

下面的完整 Bash 实验直接断言参数数量，不使用会掩盖边界差异的 echo。它自行创建两个匹配文件，检查带空格的值、空值、空 IFS 下的通配符，以及连续冒号生成的空字段。测试目录退出时自动删除，不需要读者准备目录内容。

bash --noprofile --norc <<'BASH'
set -e
set +f
unset GLOBIGNORE
shopt -u nullglob failglob dotglob
work=$(mktemp -d)
trap 'rm -rf -- "$work"' EXIT
cd "$work"
IFS=$' \t\n'
value='report final.md'
set -- $value
[[ $# -eq 2 ]]
set -- "$value"
[[ $# -eq 1 && $1 == 'report final.md' ]]
value=''
set -- $value
[[ $# -eq 0 ]]
set -- "$value"
[[ $# -eq 1 && $1 == '' ]]
touch a.txt 'two words.txt'
IFS=''
pattern='*.txt'
set -- $pattern
[[ $# -eq 2 ]]
set -- "$pattern"
[[ $# -eq 1 && $1 == '*.txt' ]]
IFS=:
record='red::blue'
set -- $record
[[ $# -eq 3 && $2 == '' ]]
printf 'colon field <%s>\n' "$@"
args=('report final.md' '' '*.txt')
set -- "${args[@]}"
[[ $# -eq 3 && $2 == '' && $3 == '*.txt' ]]
printf 'PASS: boundaries, empty values, globbing, delimiters\n'
BASH

预期输出三行冒号字段，中间一行的尖括号内为空，随后输出通过信息。前面的断言还验证了零参数和一个空参数确实不同，以及 IFS 为空时通配仍然执行。如果真实脚本仅在特定文件名下失败，可以在函数或外部命令的调用边界临时加入参数计数，并使用 Bash 的 printf %q 格式逐项显示。这个输出有助于观察换行、空格和字面星号，但调试日志不是可随意重新执行的命令格式，不应再交给 eval 处理。

来源

GNU Bash：分词，IFS 和空字段规则，已核验 2026-09-06。
GNU Bash：Shell 展开，分词先于文件名展开的顺序，已核验 2026-09-06。
GNU Bash：数组，保留参数列表边界，已核验 2026-09-06。

Shell 位置参数是一份有编号的清单

Mon, 29 Nov 2027 00:00:00 +0000

Shell 脚本接收的是有顺序的参数列表，不是需要重新按空格拆分的一整条命令字符串。位置参数通过 $1、$2 等编号暴露这份列表，$# 表示数量。固定且简单的接口可以直接使用位置，带可选设置或开关的接口则适合明确解析。无论采用哪种形式，都需要规定允许几个参数、是否允许空值，以及输入错误时怎样失败。

解释含义之前，先保住列表边界

$0 表示脚本名称等特殊身份，不属于位置参数，也不计入 $#。使用 bash -c 时，命令字符串之后的第一个参数会成为 $0，包装脚本若误以为它是 $1，就会看起来少收到一个参数。超过第九个位置必须使用花括号：${10} 是第十个参数，$10 却是第一个参数再接一个字面数字零，两种写法不能互换。

"$@" 会为每个传入参数保留一个词，包括空字符串和包含空格的值。未引用的展开可能再次分词并展开通配符，"$*" 则会把列表连成一个字符串。转发或遍历时应使用带引号的完整列表。set -- 替换当前的位置参数，shift 删除前面的若干项；这些操作在对应脚本或函数作用域中生效，不会反向改写外部调用者原来的参数列表。

空参数仍然占据一个位置。检查 $# 可以区分完全没有提供参数，与明确传入 '' 两种情况。${1:?message} 同时拒绝缺失和空值，只有接口要求非空时才合适。应先验证数量，再读取必需的位置，最后判断内容是否合法，避免在参数本来不存在时就触发与接口说明无关的展开错误。

getopts 检查语法，业务规则检查含义

可移植的 getopts 处理短选项。选项字符后面的冒号表示该选项需要一个值，但不会自动提供 --user 这类长选项支持。选项说明开头的冒号表示采用安静错误报告：未知选项产生问号，缺少值产生冒号，相关选项字符放在 OPTARG 中。脚本必须明确处理这些分支，不能因为解析循环继续运行就误以为输入合法。

OPTIND 记录解析进度。在同一 Shell 中开始解析另一份参数之前，应把它重置为一；解析完成后，使用 shift "$((OPTIND - 1))" 让剩余操作数成为当前列表。-- 结束选项处理，因此以连字符开头的文件名也能被当作操作数。普通的非选项同样会结束扫描，不能假定写在文件名后面的选项会被自动搬到前面。

解析器拿到一个值，不等于它的业务含义有效。调用者显式提供空字符串，可以满足“这里有一个选项参数”的语法要求，却不满足“名称必须非空”的接口规则。默认值也只应用于省略的可选设置，不应掩盖错误输入。诊断应写到标准错误，并在执行实际工作前返回约定的非零状态，让调用方能够可靠识别参数错误。

可复用的 Bash 解析函数应当同时局部化 OPTARG 与 OPTIND。getopts 在处理选项时会更新或取消 OPTARG；即使每次正确重置索引，未局部化的 OPTARG 仍可能破坏外层解析器状态。下面让两者都局部化，并确认调用者预先设置的哨兵值在全部调用之后仍然保留。

坏掉的样子

常见问题之一是正常输入能跑，多余的操作数却被悄悄丢弃。另一种是忘记重置解析索引，导致函数第一次调用正确，后续调用跳过部分选项。未引用转发也可能先改变参数数量，产生类似症状。应分别检查接收到的列表与解析状态，而不是不断补几个移位操作，直到某一次特定调用碰巧成功。

下面的示例明确规定一个小接口：可选的名称选项、可选的详细输出开关，以及恰好一个输入操作数。名称必须非空。函数使用 Bash 的局部变量声明，因此完整示例依赖 Bash，虽然其中的选项解析器本身是可移植的。面向其他 Shell 的脚本，应采用目标 Shell 支持的作用域规则，而不能把局部声明也当成统一标准。

快速验证

在 Bash 中运行完整代码块。开头检查第十个参数的引用方式，以及空参数是否被保留。随后测试一次合法调用，再分别测试缺值、未知选项、空名称和多余操作数。演示函数只打印解析结果，不修改文件，也不启动外部程序，所以可以直接观察参数边界，而不把其他业务副作用混进验证。

BASH_ENV= bash --noprofile --norc <<'BASH'
set -- one 2 3 4 5 6 7 8 9 ten
printf 'without-braces=<%s> tenth=<%s>\n' "$10" "${10}"
set -- '' 'two words'
printf 'count=%s\n' "$#"
for demo_arg in "$@"; do printf 'argument=<%s>\n' "$demo_arg"; done
demo_cli() {
 local OPTIND=1 OPTARG demo_option demo_name=guest demo_verbose=no
 while getopts ':n:v' demo_option; do
 case "$demo_option" in
 n) demo_name=$OPTARG ;;
 v) demo_verbose=yes ;;
 :) printf 'missing value for -%s\n' "$OPTARG" >&2; return 2 ;;
 \?) printf 'unknown option -%s\n' "$OPTARG" >&2; return 2 ;;
 esac
 done
 shift "$((OPTIND - 1))"
 if [ "$#" -ne 1 ] || [ -z "$demo_name" ]; then
 printf 'need a nonempty name and exactly one input\n' >&2
 return 2
 fi
 printf 'name=<%s> verbose=%s input=<%s>\n' "$demo_name" "$demo_verbose" "$1"
}
OPTARG=caller-sentinel
demo_cli -v -n 'Jane Doe' -- '-input file'
if demo_cli -n 2>/dev/null; then exit 1; else printf 'missing=%s\n' "$?"; fi
if demo_cli -x 2>/dev/null; then exit 1; else printf 'unknown=%s\n' "$?"; fi
if demo_cli -n '' input 2>/dev/null; then exit 1; else printf 'empty=%s\n' "$?"; fi
if demo_cli one two 2>/dev/null; then exit 1; else printf 'extra=%s\n' "$?"; fi
demo_cli second
[[ $OPTARG == caller-sentinel ]] || exit 1
printf 'caller OPTARG preserved\n'
BASH

第一行应分别得到 one0 与 ten，之后参数数量为二，打印出空字符串和带空格的第二项。合法调用保留 Jane Doe 和 -input file 的完整内容。四类错误输入都应返回状态二。最后一次调用重新使用默认名称、关闭详细开关，并接收 second，证明重复解析从新的状态开始，而不是沿用前一次的索引或选项值。

这些观察验证了接口边界，不只是证明存在一段用法提示。扩展真实命令时，应补充新选项的内容规则，同时维持已有的引用、空值和结束选项标记语义。参数能够被读到，是解析的开始；只有合法输入被接受、非法输入被明确拒绝，接口约定才真正成立。

来源

Bash 位置参数，编号参数及函数作用域规则，已核验 2026-09-07。
POSIX getopts，选项语法错误与解析状态重置，已核验 2026-09-07。

Shell 参数展开产生替代值

Tue, 16 Nov 2027 00:00:00 +0000

参数展开根据 Shell 参数产生一个值，随后命令才收到展开后的参数。它可以提供默认值、拒绝缺失配置，或者删除字符串的一部分，不必为这些操作启动额外进程。但“执行命令前展开”并不等于“初次解析脚本时就求值”：函数在被调用时读取变量当前的内容，函数定义之后修改变量，会影响后续调用。区分解析、展开和执行，才能解释为什么相同的表达式在不同时间产生不同结果。

默认值要区分未设置与空字符串

${setting:-default} 在变量未设置或者为空时使用默认值；${setting-default} 只处理未设置的情况，保留调用者明确传入的空字符串。冒号改变的是配置语义，不能当成随意省略的标点。例如空字符串可能表示关闭某个前缀，擅自用默认值替换就会改变用户的选择。${setting:+enabled} 只在变量已设置且非空时产生替代文本，去掉冒号后，已设置但为空也满足条件。

普通默认值展开不会修改变量本身。${setting:=default} 才会在选中默认分支时把结果存进变量，之后再读取就能看到新值。${setting:?message} 则在变量未设置或为空时把诊断写到标准错误，并让非交互 Shell 以非零状态退出。去掉冒号后，这两个运算符也只检查是否设置。应当先确定调用约定：允许为空、允许省略，还是必须提供，然后选择相应形式，而不是把所有配置问题都掩盖成一个默认值。

花括号还负责把变量名与相邻文本分开。"${prefix}_suffix" 是给变量内容追加后缀，"$prefix_suffix" 却读取另一个变量。用几个配置拼文件名时，看似缺值的问题可能只是变量名边界写错。应分别检查各个组成部分，再排查最终路径；一个语法完全合法的字符串，也可能混入来自错误变量的内容。

模式处理字符串，不访问文件

${name#pattern} 与 ${name##pattern} 分别删除最短和最长匹配前缀；对应的后缀运算符是 % 与 %%。这里使用 Shell 模式，不是正则表达式。匹配不到时保留原字符串，匹配成功也不会自动回写原变量。斜杠在这里就是普通的文本内容，这些运算不会查询目录、确认文件存在或者解析符号链接，因此不能用一次字符串截取证明路径安全。

如果结果必须保持一个参数，就给整个展开加双引号。"${name##*/}" 仍然会应用花括号里的模式，删除直到最后一个斜杠的前缀；外层引号保护的是展开结果，不会让内部星号失去模式含义。这些形式属于可移植的 Shell 操作，而下标截取、全局替换等还可能依赖 Bash 扩展。脚本既然用 sh 启动，就不能仅凭作者的交互环境支持某种写法而假定所有机器都支持。

默认值的选择还涉及校验边界。配置中的零、文本 false，以及只包含空白的值，都是非空字符串，不会因为使用带冒号的默认展开就被拒绝。端口、路径或数字上限是否合法，仍需单独判断；选中了默认值或通过缺值检查，都不能替代业务内容校验。

坏掉的样子

未加引号的展开结果可能继续经历分词与文件名展开。花括号只划定变量名，不保护参数边界；变量包含空格或星号时，命令可能收到额外参数，甚至收到当前目录里碰巧匹配的文件名。另外，默认表达式只有在对应分支被选中时才会展开。如果把命令替换放进默认值，那么缺值分支就可能启动进程，不能把这种表达式当成完全没有副作用的常量。

参数展开也不是命令模板系统。从变量得到的分号、引号等文本，不会自动重新解析成 Shell 语法。需要动态参数列表时，在 Bash 中使用数组，或在可移植 Shell 中明确构造位置参数；不要把整条命令存成字符串，再用 eval 解释。set -u 能发现部分未设置变量，却不能判断业务取值是否合理；pipefail 管理管道状态，也不会改变这里的字符串运算规则。

快速验证

用 Bash 运行下面的完整实验。所有变量都局限于子 Shell，输出同时显示替代值和变量实际保存的值；方括号使空字符串清晰可见。故意触发的缺值错误放在更内层的子 Shell 中，以便观察失败而不提前结束整组验证。

bash --noprofile --norc <<'BASH'
unset demo_setting
printf 'unset=[%s]\n' "${demo_setting-default}"
demo_setting=
printf 'empty=[%s] colon=[%s]\n' \
 "${demo_setting-default}" "${demo_setting:-default}"
printf 'substitute=[%s] stored=[%s]\n' \
 "${demo_setting:-fallback}" "$demo_setting"
: "${demo_setting:=saved}"
printf 'assigned=[%s]\n' "$demo_setting"
demo_name='reports/weekly report.tar.gz'
printf 'base=[%s] one=[%s] all=[%s]\n' \
 "${demo_name##*/}" "${demo_name%.*}" "${demo_name%%.*}"
printf 'original=[%s]\n' "$demo_name"
show_value() { printf 'current=[%s]\n' "$demo_setting"; }
demo_setting=later
show_value
if (unset demo_setting; : "${demo_setting:?required for demo}") 2>/dev/null; then
 printf 'unexpected success\n'
else
 printf 'missing value rejected\n'
fi
BASH

第一行应为 unset=[default]，第二行是 empty=[] colon=[default]，直接展示冒号对空值的影响。普通替代之后仍然显示 stored=[]，使用赋值运算符后才出现 assigned=[saved]。取文件名得到 weekly report.tar.gz；删除最短后缀得到 reports/weekly report.tar，删除最长后缀得到 reports/weekly report，但随后打印的原变量仍完整保留。

函数最后输出 later，证明函数定义没有把变量值冻结在解析时。末行应确认缺值被拒绝，而不出现意外成功。这组输出分别验证替代、赋值、模式删除与失败处理；单看命令返回成功，并不能证明调用者要求保留的空配置没有被错误替换。

来源

Bash 手册参数展开，定义展开运算符，已核验 2026-06-10。
POSIX Shell 参数展开，未设置与空值的区别及可移植的模式删除，已核验 2026-09-07。

umask 过滤新建权限，默认 ACL 会改变规则

Sat, 09 Oct 2027 00:00:00 +0000

进程的 umask 在普通模式位创建规则下，为新文件和目录移除权限位。应用先提供请求模式，掩码再限制这份请求。它既不是完整访问策略，也不会重写所有既有文件。如果父目录具有默认访问控制列表，创建计算方式还会改变，因此只检查进程掩码，可能无法准确预测最后得到的权限。排查时需要同时看到应用请求和目录环境。

坏掉的样子

没有默认 ACL 时，普通权限结果是请求模式与 umask 按位取反后的值进行按位与。例如请求 0666、掩码 0022，得到 0644。这个计算不是算术减法：相同掩码下请求 0600，仍然得到 0600。应用没有请求执行权限时，宽松掩码也不会主动添加执行位；掩码负责移除，而不是凭空授予应用未请求的普通权限。

限制严格的 umask 不会修复已经存在的全员可写文件。打开并截断该文件，会改变内容，却保留既有模式。后续 chmod 也可以不受当前掩码限制地扩大权限。因此，把 umask 当作权限永远不能超过的上界，会遗漏既有文件与之后权限修改两类情况。必须区分文件首次创建，以及此后围绕同一 inode 发生的操作。

父目录具有默认 ACL 时，Linux 从它派生新对象的访问 ACL，再按应用请求模式限制权限，不再按普通方式应用进程 umask。因此，即使创建者掩码是 0077，共享目录里仍可能生成组可访问文件。遇到与预期不同的模式时，应检查继承的 ACL，而不能只看到严格掩码就断言内核没有遵守权限设置。

快速验证

把脚本保存为 mask.py，在安装 Python 3 和 setfacl 的 Linux 环境中运行 python3 mask.py。临时目录所在文件系统必须支持默认 ACL。实测使用 Python 3.11.2、acl 2.3.1，以及通过 TMPDIR 选择的独立 ext4 卷。最初 tmpfs 环境拒绝设置默认 ACL，因此完整实验随后在 ext4 上重新执行：

from pathlib import Path
from tempfile import TemporaryDirectory
import os,stat,subprocess

def create(path,requested):
 fd=os.open(path,os.O_WRONLY|os.O_CREAT|os.O_EXCL,requested);os.close(fd)
def mode(path):return stat.S_IMODE(path.stat().st_mode)
previous=os.umask(0o022)
try:
 with TemporaryDirectory(prefix='xbcatm-umask-') as directory:
 root=Path(directory)
 data=root/'data';create(data,0o666);assert mode(data)==0o644
 executable=root/'executable';create(executable,0o777);assert mode(executable)==0o755
 private=root/'private';create(private,0o600);assert mode(private)==0o600
 folder=root/'folder';folder.mkdir(mode=0o777);assert mode(folder)==0o755
 assert 0o600&~0o022==0o600 and 0o600-0o022!=0o600
 print('without default ACL: requested mode AND NOT umask; 0666 becomes 0644, 0777 becomes 0755')
 os.umask(0o077)
 strict=root/'strict';create(strict,0o666);assert mode(strict)==0o600
 existing=root/'existing';create(existing,0o666);existing.chmod(0o666)
 fd=os.open(existing,os.O_WRONLY|os.O_TRUNC);os.close(fd)
 assert mode(existing)==0o666
 print('restrictive mask leaves an existing 0666 file unchanged; chmod can widen permissions later')
 acl_folder=root/'acl';acl_folder.mkdir()
 subprocess.run(['setfacl','-d','-m','u::rwx,g::rwx,o::---',str(acl_folder)],check=True)
 inherited=acl_folder/'inherited';create(inherited,0o666)
 restricted=acl_folder/'restricted';create(restricted,0o600)
 assert mode(inherited)==0o660 and mode(restricted)==0o600
 print('with default ACL and umask 0077: request 0666 yields 0660; request 0600 still yields 0600')
 status=dict(line.split(':',1) for line in Path('/proc/self/status').read_text().splitlines() if ':' in line)
 assert int(status['Umask'].strip(),8)==0o077
 print('/proc/self/status observes this process mask without temporarily changing it')
finally:os.umask(previous)

掩码为 0022、没有继承默认 ACL 时，请求 0666 得到 0644 文件；请求 0777，普通文件和目录均得到 0755；请求 0600 则仍为 0600。脚本还检查算术减法会对最后一种请求产生不同结果，直接暴露常见计算错误。这些结果说明，需要理解位操作，而不是把八进制权限数字当作普通额度相减。

改为掩码 0077 后，新文件请求 0666，最终得到 0600。另一个文件被明确 chmod 为 0666，随后以截断方式打开，但没有创建操作，其模式保持 0666。这个对照区分首次创建与既有 inode 上的后续操作，而不是假定每次 open 都重新套用创建策略。严格掩码无法替代对存量权限的检查。

接着，脚本给父目录设置默认 ACL：所属用户和组拥有完整权限，其他用户没有权限。进程掩码仍为 0077，新文件请求 0666，却得到 0660。继承 ACL 在严格掩码下保留组读写权限，同时应用请求排除了执行权限。结果来自实际文件状态检查，不是只看 setfacl 命令执行成功就推测新文件行为。

同一目录中另一个文件请求 0600，结果仍为 0600。默认规则不会添加请求模式排除的权限。这两种请求一起验证了默认 ACL 对普通掩码规则的例外，也验证应用显式请求仍然参与限制。只观察较宽的一种结果，容易误以为 ACL 可以忽略应用的所有权限请求，因此必须保留这个对照。

脚本从 /proc/self/status 读取 Umask，确认进程掩码仍为 0077，在 finally 中恢复原值并清理临时目录。如果文件系统无法设置 ACL，命令会失败，不会跳过核心例外后声称完整通过。前一次环境失败与之后完整执行的结果分别保留，避免把环境能力缺失误写成契约已经验证。

在正确层级应用创建策略

umask 会随正常进程创建继承，并在执行另一个程序后保留。服务或命令应通过真实启动路径设置它。无关终端的掩码不会追溯改变已经运行的进程，shell 配置文件也只有被启动链读取时才生效。需要验证的是最终创建文件的进程状态，而不是另一个方便观察的控制终端。

对于共享相关文件系统状态的线程，umask 是进程范围的设置。为了读取旧值而临时改动它，可能干扰同时发生的文件创建。Linux 上读取 proc 状态字段可以避免这种修改。应用如果必须创建私有文件，应请求足够严格的权限，并核对真实存储环境，不能依赖一次短暂改掩码覆盖所有并发创建行为。

还应一起检查父目录访问权限、所有权、ACL 和最终文件权限。0660 文件位于不可访问父目录中时，组用户并不会自动获得完整访问路径；模式位也不能单独描述所有命名 ACL 条目。本实验验证创建结果，端到端访问则需要让预期身份沿完整路径实际尝试。权限数字正确，只是整条访问条件中的一部分。

来源

umask(2)，创建掩码、继承、默认 ACL 交互与 proc 检查，已核验 2026-09-12。
acl(5)，默认 ACL 继承与请求模式对权限的约束，已核验 2026-09-12。
open(2)，创建模式与打开或截断既有文件，已核验 2026-09-12。

别名免除重复敲击

Mon, 04 Oct 2027 00:00:00 +0000

别名在 Bash 读取命令时，把命令位置的一个词替换成一段 Shell 文本。alias ll='ls -l' 这种个人快捷方式很方便，但别名并不是一个可执行文件，也没有独立的位置参数作用域。非交互 Bash 默认关闭别名展开，脚本却可以明确启用它；“默认不展开”与“脚本中绝对不能使用”是两回事。理解这个区别，才能解释为什么终端里好用的简称到了自动化环境就找不到。

替换发生在读取输入时

命令位置上没有被引用的词，才可能被当成别名展开。定义 ll 后，ll 'two words' 仍会把带空格的文本作为一个参数传给命令，不能笼统地说别名必然破坏参数引用。真正的限制是：别名没有属于自己的 $1，也不能像函数那样拥有并重新排列一组独立的参数。调用者后面追加的参数，只是继续参与替换后的命令解析。

替换文本甚至可以包含管道或多条命令，因此别名在语法上并不局限于单一程序。代价是读者更难直接看出简称背后的行为。Bash 会继续检查替换文本的第一个词，但不会再次展开当前正在展开的同名别名，所以 alias ls='ls -F' 不会无限递归。还有一个容易忽略的规则：别名值末尾如果留有空白，紧随其后的命令词也会接受别名检查，不应把尾部空格当成无意义的排版。

定义本身的引号还决定另一层求值时机。单引号让美元符号保留到替换文本以后被解释；双引号却可能在定义别名时就展开变量。原本想跟随目录变量变化的快捷方式，于是可能固定住旧值。遇到这种差异时，应检查实际保存的别名定义，而不只是回看自己最初输入的那一行。

作用域与生效时机分开看

别名属于当前 Shell，不是可以导出给新 Bash 进程的环境变量。圆括号创建的子 Shell 会继承当前 Shell 状态，这与重新启动一个 Bash 程序不同。新进程读取启动文件后出现同名别名，表示配置又执行了一遍，并不证明别名通过环境自动传递。因此排查问题时，应确认命令究竟由当前交互 Shell、圆括号子 Shell，还是另一个程序启动。

shopt -s expand_aliases 能在非交互 Bash 中启用展开，但定义仍须在使用它的输入被读取之前生效。Bash 会先读完一整行或完整复合命令，再执行其中的内容。同一行先定义别名、后调用新名字，并不能赶在解析后半行之前建立定义；把定义塞进正在读取的函数体，也存在同样的时机问题。把定义单独放一行，比依赖分号后的即时生效可靠。

做可复现实验时，还要注意：禁用登录和交互启动文件，并没有禁用非交互的 BASH_ENV 钩子。除了明确选项，还应使用受控环境，否则继承的启动文件可以在第一条测试命令之前定义同名函数、安装别名或改变选项，让观察结果掺入会话配置。

坏掉的样子

函数定义被读取时，函数体中的别名可能已经展开。后来修改别名表，并不会重写那份已经解析好的函数体，所以函数仍执行旧内容，而直接调用别名却执行新内容。需要行为清晰、参数可控的复用逻辑时，应直接定义函数，并使用带双引号的 "$@" 转发参数，保留空字符串以及带空格的参数边界。

另一个常见误判，是把交互快捷方式当成其他程序也能启动的命令。进程启动器不会读取你的交互别名表。可以在发生问题的 Shell 中使用 type name 查看解析结果，用 alias name 检查定义，用 unalias name 删除定义。给命令词加引号或反斜杠会阻止别名展开，但之后仍可能解析成函数或内建命令；需要明确选择某个可执行文件时，使用它的路径。

快速验证

下面的实验只使用诊断用名称和内建命令，分别观察关闭展开、打开展开、同一行定义，以及函数在别名改变之前被解析的情况。预期失败的退出码紧跟着读取，避免后面的打印命令覆盖状态。整个过程局限在新 Bash 中，不改变外层交互会话的快捷方式。

BASH_ENV= bash --noprofile --norc <<'BASH'
shopt -u expand_aliases
alias demo_alias='printf "alias=<%s>\n"'
demo_alias hidden 2>/dev/null
printf 'disabled=%s\n' "$?"
shopt -s expand_aliases
demo_alias 'two words' ''
alias demo_late='printf "late\n"'; demo_late 2>/dev/null
printf 'same-line=%s\n' "$?"
demo_late
alias demo_version='printf "old\n"'
demo_function() { demo_version; }
alias demo_version='printf "new\n"'
demo_function
demo_version
unalias demo_alias
if command -v demo_alias >/dev/null 2>&1; then
 printf 'unexpected command\n'
else
 printf 'alias removed\n'
fi
BASH

关闭展开时应得到状态 127。打开后依次输出 alias=<two words> 与 alias=<>，表明带空格的参数和空参数均被保留。同一行的首次调用仍返回 127，下一行才打印 late。随后函数打印 old，直接调用打印 new，最后确认别名已移除。

这组结果给出了具体边界：简单别名可以保留调用者的引用，非交互展开可以配置，而读取时替换会让函数保留旧行为。共享脚本中的复用逻辑应放进脚本明确加载的函数或可执行文件；个人别名则保留为当前会话中可查看、可移除的简写。

来源

Bash 参考手册：别名，维护者托管的手册对展开时机和非交互行为的说明，已核验 2026-09-07。
POSIX 别名替换，命令词替换及引用规则，已核验 2026-09-07。
GNU Bash：启动文件，非交互 BASH_ENV 行为（官方索引文本），已核验 2026-10-15。

重定向重新安排流向

Wed, 29 Sep 2027 00:00:00 +0000

重定向在命令执行前改变它的文件描述符。Shell 从左到右处理每一项，遇到打开文件或复制描述符的操作，就在那个位置完成相应变更。描述符零、一、二通常分别表示标准输入、标准输出和标准错误。把命令行读成对这些句柄的顺序操作，就能解释诊断为什么去了错误的位置，也能解释文件为什么还没有被程序读取就已经变空。

打开文件本身就可能改变数据

>output 打开输出文件，并且通常把已存在的普通文件截断为零长度；>>output 使用追加方式，<input 则打开文件供读取。这些动作由 Shell 完成，不是命令所指程序的内部行为。如果必须打开的目标失败，命令不会执行，但此前已经成功的重定向仍可能创建或截断其他文件。不能把“程序没有启动”理解成“整条命令完全没有副作用”。

因此，sed expression input >input 会在转换程序读取数据之前破坏原文件。即便先写 <input 打开输入，后续重定向截断同一个底层文件，也不能保住那些内容。应写入独立临时文件，检查转换状态与结果，再根据文件归属、权限和所在文件系统，明确执行替换步骤。输入输出恰好同名时，不能指望 Shell 自动替你实现安全的原地编辑。

复制记住的是当下的目标

>log 2>&1 先让描述符一指向日志，再让描述符二引用同一个已打开目标。2>&1 >log 则先复制原来的标准输出，之后只改变描述符一，因此标准错误仍留在原目标，例如终端或负责捕获输出的管道。这里复制的是描述符引用，不是文件内容，也不是给两个数字建立一个会随之后续变化的动态连接。

Bash 的 &>log 可以简写同时重定向两条流，而 >log 2>&1 也适用于可移植 Shell。不要把它写成 >log 2>log：后者分别打开同一个文件，两份打开状态拥有独立偏移量，输出可能相互覆盖。即使描述符共享一个目标，应用程序自身的缓冲仍会影响消息真正写出的时间，所以合并日志也不自动保证业务事件严格按发生顺序排列。

管道会先把标准输出连接到下一阶段，然后才应用命令自己的重定向。因此 producer >file | consumer 的生产者把输出交给了文件，消费者反而读不到那些数据。相反，producer 2>&1 | consumer 会把诊断也送进管道。如果下游要求机器可解析的记录，把面向人的错误文本混进去，就可能破坏原本合法的输入格式。

坏掉的样子

文件名来自变量时应加引号，避免空格让目标展开成多个词。描述符编号必须紧贴操作符：2>errors 重定向标准错误，2 >errors 却把数字二作为普通参数传给命令，并重定向标准输出。一个空格就可能同时改变程序收到的输入参数和输出位置，排查时不能只看目标文件名有没有拼对。

Bash 的 set -C 启用禁止覆盖模式，通常会拒绝用普通输出重定向覆盖已存在的普通文件。这有助于防止误操作，但不是备份机制，也不是对所有文件类型的统一保护；>| 会明确绕过这个选项。还要区分单条命令的临时重定向与 exec >log：后者修改当前 Shell 的描述符，可能把后续所有命令的输出一起转走，不能在交互验证时无意间让整个会话失声。

快速验证

下面的完整实验使用 Bash 和常见 Unix 工具，只会截断、删除刚创建的专用临时文件。它比较两种重定向顺序，演示输入输出同文件时的数据丢失，并验证目标无法打开时函数体确实没有运行。清理步骤逐个列出实验文件，不使用递归删除，也不会触碰原有文件。

bash --noprofile --norc <<'BASH'
set -eu
demo_dir=$(mktemp -d)
trap 'rm -f "$demo_dir/both" "$demo_dir/out" "$demo_dir/input"; rmdir "$demo_dir"' EXIT
emit() { printf 'out\n'; printf 'err\n' >&2; }
emit > "$demo_dir/both" 2>&1
demo_captured=$(emit 2>&1 > "$demo_dir/out")
[ "$(cat "$demo_dir/both")" = "$(printf 'out\nerr')" ]
[ "$(cat "$demo_dir/out")" = out ]
[ "$demo_captured" = err ]
printf 'both:\n'
cat "$demo_dir/both"
printf 'out-file=[%s] captured=[%s]\n' \
 "$(cat "$demo_dir/out")" "$demo_captured"
printf 'seed\n' > "$demo_dir/input"
sed 's/seed/replaced/' "$demo_dir/input" > "$demo_dir/input"
[ ! -s "$demo_dir/input" ]
printf 'input truncated\n'
if (set -C; emit > "$demo_dir/both") 2>/dev/null; then
 printf 'unexpected overwrite\n' >&2
 exit 1
else
 printf 'noclobber rejected overwrite\n'
fi
demo_ran=no
mark_run() { demo_ran=yes; }
if mark_run 2>/dev/null > "$demo_dir/missing/output"; then
 printf 'unexpected redirection\n' >&2
 exit 1
else
 [ "$demo_ran" = no ]
 printf 'function-ran=%s\n' "$demo_ran"
fi
BASH

合并文件应打印 out 和 err。交换顺序后，输出文件只含 out，变量单独捕获到 err。转换实验报告输入已经变空，因为截断先于程序读取。最后两行分别证明禁止覆盖选项拒绝了替换，以及目标打开失败时仍为 function-ran=no，函数中的赋值没有执行。

明确比较与失败分支让异常结果以失败状态退出，不会只打印意外信息后继续成功结束。这些检查同时观察文件内容与命令是否真正执行，而不是只依赖最后一条打印命令成功。在真实脚本中，还要把生产者退出状态与日志一起保留下来：错误消息即使准确进入了日志，也不能把失败操作变成成功。只有分别保留流向和状态两类证据，后续恢复判断才有可靠依据。

来源

Bash 参考手册：重定向，从左到右的描述符变更及禁止覆盖行为，已核验 2026-09-07。
POSIX Shell 重定向，可移植的重定向运算符及文件打开语义，已核验 2026-09-07。

管道让进程彼此流式连接

Tue, 28 Sep 2027 00:00:00 +0000

shell 管道把一个命令的标准输出连接到下一个命令的标准输入。各段命令可以并发运行，生产者不必全部完成后消费者才开始处理。这种连接支持增量处理，却不保证任一程序真的采用增量算法。用户态缓冲、提前结束以及各阶段的退出状态，都会影响整项操作是否达到预期。理解管道时，需要同时观察数据流、文件描述符生命周期和进程结果，不能只看最后一行输出。

有限容量的字节流

管道传输的是字节，不是自带边界的记录。读者不能假设每次读取恰好得到一行，也不能假设一次读取对应生产者的一次写入。需要消息边界的程序必须自己定义和解析。标准错误默认独立于管道连接，因此，上游诊断可能显示在终端，却不会进入下游过滤器。是否合并诊断和数据应当明确决定，避免错误文本污染本来供机器读取的内容。

内核缓冲区容量有限。对于阻塞操作，管道满时写者等待；管道空但仍有写端打开时，读者等待。这种反压限制生产者在这个管道上领先消费者的距离。容量取决于操作系统和配置，并不是普遍固定为六十四千字节。程序自身仍可能维护不断增长的数据结构，因此，使用管道不等于整个处理链的内存已经有界，必须另外检查各段算法。

用户态缓冲还可能引入额外等待。某个程序向终端逐行刷新，改成管道输出后却可能先积累较大的块。此时消费者看起来没有动静，并不代表内核丢了数据；数据可能尚未离开生产者的用户态缓冲。应先检查程序提供的流式处理和刷新控制，再考虑调整内核限制。完整排序等转换本身也需要先看到更多输入，添加随意的睡眠无法改变这种依赖。

原子写入与缓冲容量是不同属性。Linux 对不超过 PIPE_BUF 的适当写入提供不与其他写者交错的保证，并有阻塞模式条件；这仍然不会为读者建立消息边界。几次短写入可能被一次读取取得，一次写入也可能分几次才读完，不能把某次观察到的块大小当作解析协议。

坏掉的样子

只有所有指向写端的文件描述符都关闭后，读者才会看到文件结束。如果某个子进程继承了不再使用的写端，即使看起来生产者已经退出，消费者也可能一直等不到结束。反方向上，所有读端关闭后继续写入会产生 SIGPIPE；忽略这个信号时，写操作会以 EPIPE 错误失败。因此，消费者主动提前结束，也可能让原本正常的生产者以非零状态退出。

Bash 默认返回最后一段命令的状态。上游失败、下游 cat 成功读完部分数据时，整体可能仍然成功。开启 pipefail 后，整体返回从左到右最靠右的非零状态，并不是时间上最先失败的进程，也不是最左侧失败命令。PIPESTATUS 数组短暂保留每段结果，应立即保存，因为后面一次赋值或打印就可能替换这份观察记录。

Bash 管道中的阶段通常运行在子 shell 环境。在管道右侧循环里给变量赋值，通常不会修改调用者的变量。lastpipe 选项在关闭作业控制时可以改变最后一段的执行位置，因此依赖状态保留的代码必须明确 shell 配置。需要保留循环状态时，也可以让循环直接通过重定向读取输入，避免把它放进管道带来的作用域变化。

前台 Bash 管道会等待各阶段结束，并不是消费者读到第一行就立即返回。如果生产者捕获断管错误后继续执行其他工作，整体完成时间仍会被拖延。因此，管道应被理解为多个具有独立结果、通过描述符连接的进程，不能假设它们总会像一个不可分割操作一样共同成功或共同停止。

快速验证

下面实验需要 Bash、cat、yes 和 head。它先用主动返回七的生产者比较默认状态和 pipefail，然后构造两段都失败的管道，最后检查提前关闭的消费者。仅在收集预期非零结果时关闭 errexit，取得结果后立即重新开启，再执行断言。

bash --noprofile --norc <<'BASH'
set -e
set +o pipefail
set +e
(printf 'partial\n'; exit 7) | cat >/dev/null
plain=("$?" "${PIPESTATUS[@]}")
set -e
[[ ${plain[*]} == '0 7 0' ]]
set -o pipefail
set +e
(printf 'partial\n'; exit 7) | cat >/dev/null
strict=("$?" "${PIPESTATUS[@]}")
set -e
[[ ${strict[*]} == '7 7 0' ]]
set +e
(exit 7) | (exit 4)
multiple=("$?" "${PIPESTATUS[@]}")
set -e
[[ ${multiple[*]} == '4 7 4' ]]
set +e
yes | head -n 1 >/dev/null
early=("$?" "${PIPESTATUS[@]}")
set -e
[[ ${early[0]} -ne 0 && ${early[1]} -ne 0 && ${early[2]} -eq 0 ]]
printf 'default: %s\npipefail: %s\nrightmost: %s\nearly close: %s\n' \
 "${plain[*]}" "${strict[*]}" "${multiple[*]}" "${early[*]}"
printf 'PASS: aggregate and individual stage outcomes\n'
BASH

每个打印数组的第一项是管道整体状态，后面按源码顺序列出各段状态。前三组预期分别为零七零、七七零、四七四。最后一组中，head 成功，而 yes 返回非零；断言没有硬编码具体信号编号，避免把平台表示方式混入行为要求。生产环境应区分这种主动提前停止与必需输出丢失，不能看到 pipefail 非零就无条件重试全部操作。吞吐量、缓冲延迟和内存峰值仍需独立测量，这些退出状态断言并没有验证性能。

来源

GNU Bash：管道，进程执行和整体状态规则，已核验 2026-09-06。
Linux man-pages：pipe(7)，字节流、描述符生命周期、容量与断管信号，已核验 2026-09-06。
GNU Bash：特殊参数，最近命令的退出状态，已核验 2026-09-06。

作业控制在进程组之间交接终端前台

Mon, 27 Sep 2027 00:00:00 +0000

交互式作业控制让 shell 管理共享控制终端的多个进程组。终端同一时刻只有一个前台组，其他作业可以在后台运行，也可以保持停止状态。前台归属、是否运行和 shell 的作业表，是三种不同状态。后台作业不等于已经暂停，停止作业也不等于已经终止；判断当前交互为什么没有进展，需要先分清这些状态。

坏掉的样子

启用终端信号处理时，输入已配置的中断或暂停字符，会由终端驱动向前台组发送信号，不是只发送给最后打印文字的那个进程。控制字符重新映射、终端模式变化以及应用信号处理函数，都可能改变结果。因此只说按某个键，并不能保证在每个程序和每套终端配置中得到相同反应，还要核对实际处理条件。

普通后台作业尝试读取自己的控制终端时，会被 SIGTTIN 停止。把它放到后台，并不会给它单独分配一份键盘输入流。输出又有不同规则：后台写入通常允许，还会受 TOSTOP 等终端设置影响。因此后台执行不意味着彻底脱离终端，输入、输出和前台信号各有自己的约束，需要分别观察。

%1 这类作业标识属于某个 shell 的作业表，不是全局进程编号。换一个终端或进入非交互 shell 后，不能假定相同号码仍然管理相同任务。管道和后台命令如何分组，也取决于真实 shell 调用是否启用了作业控制。交互终端中看见的行为，不能不加检查地套到所有脚本启动路径上。

快速验证

把脚本保存为 jobcontrol.py，在装有 Bash 和 Python 的 Linux 环境中运行 python3 jobcontrol.py。本轮使用 Linux 6.18.44、Bash 5.2.37 和 Python 3.12.14 原样重跑了两种语言的样本。脚本创建自己的伪终端与交互 Bash，不会把控制字符发给你用于启动它的终端：

from pathlib import Path
import os,pty,re,select,signal,termios,time

pid,master=pty.fork()
if pid==0:
 attributes=termios.tcgetattr(0);attributes[3]&=~termios.ECHO;attributes[3]|=termios.ISIG|termios.ICANON
 attributes[6][termios.VINTR]=b'\x03';attributes[6][termios.VSUSP]=b'\x1a';attributes[6][termios.VEOF]=b'\x04'
 termios.tcsetattr(0,termios.TCSANOW,attributes)
 os.execve('/bin/bash',['bash','--noprofile','--norc','-i'],{'PATH':'/usr/bin:/bin','TERM':'dumb','LC_ALL':'C','PS1':'XB-PROMPT> ','HISTFILE':'/dev/null'})
known_groups={pid};pending=b''
def until_prompt():
 global pending
 deadline=time.monotonic()+5
 while b'XB-PROMPT> ' not in pending:
 remaining=deadline-time.monotonic();assert remaining>0,pending
 ready,_,_=select.select([master],[],[],remaining);assert ready,pending
 chunk=os.read(master,65536);assert chunk,'PTY closed before prompt';pending+=chunk
 output,pending=pending.split(b'XB-PROMPT> ',1)
 return output.decode(errors='replace')
def command(text):os.write(master,text.encode()+b'\n');return until_prompt()
def wait_for(predicate):
 deadline=time.monotonic()+5
 while not predicate():
 assert time.monotonic()<deadline,'terminal state did not change';time.sleep(0.01)
def state(process):
 try:return (Path('/proc')/str(process)/'stat').read_text().rsplit(') ',1)[1].split()[0]
 except FileNotFoundError:return None
try:
 until_prompt();assert os.tcgetpgrp(master)==pid
 os.write(master,b'sleep 60 | cat\n')
 wait_for(lambda:os.tcgetpgrp(master)!=pid)
 group=os.tcgetpgrp(master);known_groups.add(group)
 def pipeline_started():
 children=[]
 for process in Path('/proc').iterdir():
 if not process.name.isdecimal():continue
 try:
 fields=(process/'stat').read_text().rsplit(') ',1)[1].split()
 if int(fields[1])==pid:
 children.append(((process/'comm').read_text().strip(),int(fields[2])))
 except (FileNotFoundError,ProcessLookupError):continue
 return sorted(children)==[('cat',group),('sleep',group)]
 wait_for(pipeline_started)
 os.write(master,b'\x1a');output=until_prompt()
 assert 'Stopped' in output and os.tcgetpgrp(master)==pid,output
 assert 'Stopped' in command('jobs -l')
 print('Ctrl-Z stops the foreground pipeline and returns the terminal to the interactive shell')
 command('bg %1');assert os.tcgetpgrp(master)==pid
 os.write(master,b'fg %1\n');wait_for(lambda:os.tcgetpgrp(master)==group)
 os.write(master,b'\x03');until_prompt()
 assert 'RESULT:130' in command("printf 'RESULT:%s\\n' \"$?\"")
 print('bg resumes without foreground ownership; fg restores ownership; Ctrl-C gives this pipeline status 130')
 output=command("cat & printf 'BG:%s\\n' \"$!\"")
 background=int(re.search(r'BG:(\d+)',output)[1]);known_groups.add(background)
 wait_for(lambda:state(background)=='T')
 assert os.tcgetpgrp(master)==pid
 assert 'Stopped (tty input)' in command('jobs -l')
 print('a background reader is stopped by terminal input rules, rather than receiving the shell keyboard stream')
 os.write(master,b'fg %+\n');wait_for(lambda:os.tcgetpgrp(master)==background)
 os.write(master,b'hello\n\x04');output=until_prompt();assert 'hello' in output,output
 assert 'RESULT:0' in command("printf 'RESULT:%s\\n' \"$?\"")
 print('foregrounding that reader lets it read; EOF ends it normally; all jobs are reaped')
 assert not command('jobs -p').strip()
 os.write(master,b'exit\n');waited,status=os.waitpid(pid,0);assert waited==pid and os.WIFEXITED(status)
 pid=None
finally:
 if pid is not None:
 for group in known_groups:
 try:os.killpg(group,signal.SIGKILL)
 except ProcessLookupError:pass
 os.waitpid(pid,0)
 os.close(master)

样本启用终端信号处理和规范输入模式，明确配置中断、暂停与 EOF 字符，并关闭输入回显。Bash 启动时不加载用户配置文件，使用可识别提示符。这些条件使实验不依赖用户别名、提示符命令或自定义快捷键；观察到的行为来自样本明确建立的终端状态，而不是碰巧继承的交互环境。

Bash 首先在前台运行 sleep 与 cat 管道，控制进程观察到终端前台 PGID 从 Bash 变成管道。本轮有一次在只确认前台 PGID 变化后发送暂停字符，最终等待超时；没有追踪到内核层面的确切原因。因此现在先从 Linux 的进程信息中确认本实验的 sleep 与 cat 都已启动且位于预期进程组，再发送暂停字符。这个检查只用于私有、受控且尚未退出的两个子进程，不是通用的进程发现方法。发送暂停字符后，作业停止，输出 Stopped，终端前台回到 Bash。jobs -l 确认 shell 仍然保留该作业记录。停止并没有销毁任务，因此后续仍可恢复，而不是必须重新启动一份新的工作。

执行 bg %1 后，管道恢复，Bash 仍保留终端前台；fg %1 再把前台归属交回管道。发送中断字符后，采用默认行为的这条管道结束，Bash 报告状态一百三十。这是此次命令的实测结果，不代表每个应用都必须响应 INT 退出，也不代表所有运行时都使用相同数字表达信号终止。

脚本接着启动后台 cat，记录其 PID，并等待进程进入停止状态。Bash 报告 Stopped (tty input)，说明它遇到终端输入限制，没有完成，也没有读走 shell 的下一条命令。后台读取期间，shell 始终是终端前台组。这样可以把等待交互资格，与程序崩溃、正常结束或主动睡眠分开解释。

将该读取者调到前台后，它能收到 hello；在规范输入的空行位置发送 EOF 字符，使它正常结束。Bash 随后报告零状态，作业表为空。控制进程退出 Bash 并回收它；断言失败时，清理也只针对实验创建的隔离进程组。整个流程验证停止、恢复、输入和退出，而不是只检查命令是否被 shell 接受。

明确工作寿命和输入来源

停止作业不需要交互输入就能继续时，可以使用 bg；再次需要终端时使用 fg。把输入重定向到合适文件或管道，可以让后台工作不依赖键盘读取，但不会自动让它脱离会话，也不会定义登录结束时的行为。因此“在后台运行”只回答当前调度与交互关系的一部分，不能替代完整生命周期设计。

需要跨交互会话持续运行，并明确重启、日志和资源策略的工作，应交给服务管理器。shell 作业表适合管理当前交互任务，却不是持久服务状态。把任务移出作业表，或者调整挂断信号处理，也只解决更窄的问题，不能直接等同于已经建立可靠的后台服务监督。

当作业看似冻结，应先检查它是停止、等待数据，还是仍在计算，再决定是否发送终止信号。需要把作业标识、PID、PGID 与终端前台组对应起来，才能避免把正常的终端输入停止误判为崩溃。正确识别状态，有助于恢复原本需要的交互，同时保留仍然有效的工作进度。

来源

Bash job-control basics，前台进程组、终端输入、暂停与作业状态，已核验 2026-10-15。
Bash job-control builtins，jobs、bg、fg 与 shell 局部作业标识，已核验 2026-10-15。
termios(3)，终端控制字符与信号生成，已核验 2026-10-15。
tcgetpgrp(3)，读取与选择终端前台进程组，已核验 2026-10-15。
proc_pid_stat(5)，用于受控子进程就绪检查的父进程与进程组标识，已核验 2026-10-15。
proc_pid_comm(5)，仅用于识别本实验受控子进程的命令名称，已核验 2026-10-15。

环境变量属于各自的进程

Sat, 25 Sep 2027 00:00:00 +0000

环境是程序启动时收到的一组名称与字符串值。子进程通常接收父进程选定的环境，修改自己的副本不会回写父进程或兄弟进程。这是一条有用的配置边界，却不是命令没有副作用的保证：程序仍可能根据配置修改共享文件、数据库或其他资源。理解变量如何传递，与判断程序实际会做什么，是两个需要分别核对的问题。

导出决定另一个程序能收到什么

Shell 变量与环境条目有关联，但并不是同一概念。DEMO_SETTING=local 创建或更新 Shell 参数，export DEMO_SETTING 才把它标记为启动外部命令时应包含的环境项。父 Shell 能打印变量，不代表新启动的 Bash 就能看到未导出的值。把赋值写进某个配置文件，也不会让每个 Shell 自动读取它；还必须确认文件是否在对应启动路径上被加载。

Bash 从环境继承的变量已经带有导出属性，之后重新赋值会保留该属性。因此子进程修改值后，再启动孙进程时可以直接传递新值，不要求每一代重复写一次导出命令。unset 删除变量，Bash 的 export -n 则取消导出属性但保留当前 Shell 中的值。真正需要确认的是直接启动者传入了什么，而不是机械地搜索祖先脚本里出现了多少次导出语句。

子 Shell 不等于重新执行一个 Shell 程序

圆括号命令组和命令替换使用从当前 Shell 复制出来的子 Shell 环境，所以能够看到从未导出的普通 Shell 变量。它们的修改仍不会回到外层。这与重新执行一个 Bash 程序不同：后者收到的是导出的环境条目，不是父 Shell 整张参数表。若把两种情况都简单称为“子进程只认识已导出变量”，就会错误解释圆括号内的实际行为。

使用点命令加载文件时，文件中的命令在当前 Shell 执行，赋值因而能直接改变调用者。这并没有打破进程边界，因为根本不是另一个进程把修改传回来。被加载的文件是可执行 Shell 代码，不是被动的数据文件；只有当你确实打算在当前上下文执行那些内容时，才应加载它。文件扩展名叫配置，并不会改变这一点。

单次调用配置有自己的生命周期

DEMO_SETTING=once external-command 为一次外部命令提供值，不会永久改写外层 Shell 的对应变量。这条结论针对外部命令；特殊内建命令、函数等结构的赋值行为，还受到具体 Shell 规则影响。因此不能进一步推导出“所有看起来像命令的写法都会启动隔离进程”，更不能用这种推断判断函数或者点命令是否会改动当前状态。

在操作系统接口上，execve 接收明确的环境数组，替换当前进程映像，本身并不创建新进程。启动者可以保留、过滤或重建环境，这解释了为什么权限切换、服务管理器以及容器配置会产生不同于交互终端的变量。只有进程父子关系仍不足以证明应用最终收到的配置；应沿真正的启动接口检查传入值，而不是假设环境在整条链路上原样保留。

坏掉的样子

修改终端里的环境，不会更新已经运行的服务。修改环境文件，也要等相关启动器重新读取并启动进程才会生效，除非应用自己实现了配置重载机制。排查时应确认服务使用的配置路径，并在真正处理请求的进程中验证行为。另一个终端里打印出新值，只能证明那个终端的状态发生了变化，不能代替服务侧验收。

缺失与空字符串也要区分，应用可能给它们不同含义。环境字符串不能包含内嵌的空字符，平台还限制参数与环境的总大小，因此不适合装任意二进制载荷或无限增长的文档。诊断时只检查必要的非敏感键，不要直接输出整个环境；完整环境中可能混有其他工具继承的凭据，而本次故障根本不需要这些内容。

快速验证

下面的 Bash 示例只打印专用演示变量，不读取外部配置文件，也不改变外层终端环境。传给点命令的短文档已经把测试所用配置完整写在示例中，便于检查将执行的内容。各行输出分别对应不同的变量传递边界，而不是靠查看某个配置声明就推断它已经生效。

BASH_ENV= bash --noprofile --norc <<'BASH'
unset DEMO_SETTING
DEMO_SETTING=local
printf 'shell=%s\n' "$DEMO_SETTING"
bash --noprofile --norc -c 'printf "unexported-child=%s\n" "${DEMO_SETTING-unset}"'
(printf 'subshell=%s\n' "$DEMO_SETTING")
export DEMO_SETTING
bash --noprofile --norc <<'CHILD'
printf 'exported-child=%s\n' "$DEMO_SETTING"
DEMO_SETTING=child
bash --noprofile --norc -c 'printf "grandchild=%s\n" "$DEMO_SETTING"'
CHILD
printf 'parent-after-child=%s\n' "$DEMO_SETTING"
DEMO_SETTING=once bash --noprofile --norc -c 'printf "one-command=%s\n" "$DEMO_SETTING"'
printf 'parent-after-command=%s\n' "$DEMO_SETTING"
. /dev/stdin <<'CONFIG'
DEMO_SETTING=sourced
CONFIG
printf 'parent-after-source=%s\n' "$DEMO_SETTING"
BASH

未导出变量时，新 Bash 打印 unset，圆括号子 Shell 却能看到 local。导出之后，新子进程收到 local，修改自己的副本，再把 child 传给孙进程；外层 Shell 仍是 local。单次覆盖打印 once，紧接着检查父级仍然得到 local，说明覆盖没有反向传播。

最后，点命令把当前这层演示 Shell 的值改成 sourced。这些结果共同区分普通参数、导出条目、子 Shell 副本、单次调用覆盖，以及在当前 Shell 中执行代码。实验确认的是变量作用域，并没有宣称应用不会产生其他副作用，也没有代替对真实服务部署配置的检查。

来源

Bash 执行环境，导出条目与子 Shell 复制状态的区别，已核验 2026-09-07。
Bash 环境，导出属性与单次命令赋值，已核验 2026-09-07。
POSIX exec 函数，进程映像替换及显式环境数组，已核验 2026-09-07。

Bash 的通配符在命令执行前就展开

Wed, 08 Sep 2027 00:00:00 +0000

Bash 命令中的通配符通常会在目标程序启动前变成一组路径。它让批量处理很方便，也让同一行命令受到当前目录和 shell 选项的影响。程序拿到的是已经形成的参数，不会收到标记来告诉它哪些参数来自星号。因此，写命令时应先确定：希望传入实际匹配的文件，还是希望把模式本身交给另一个程序解释。两者需要不同的引号写法，不能依靠目标程序猜测意图。

先匹配，再保留参数边界

Bash 先进行分词，再进行文件名展开。没有引用的星号、问号和方括号模式可能因此生成多个参数。但匹配到的文件名即使包含空格，也仍然是一个参数，因为文件名展开之后不会再执行一次分词。常见问题发生在下一步：循环拿到了完整路径，却用没有引号的变量把它传给另一个命令。循环体中的 "$file" 仍然必要，不能因为前一步通配成功就省掉。

如果接收方需要模式，就应引用模式。例如 find . -name '*.txt' 将匹配规则交给 find；去掉引号后，Bash 会先在当前目录展开它，find 得到的可能是多个文件名，已经不是原来要表达的条件。变量里包含星号时也一样：引用变量会传递字面星号，不引用则可能触发文件名展开。引号只控制当前 shell 如何形成参数，不会禁止接收方按自己的语法解释收到的文本。

通配符匹配目录项，并不保证结果都是普通文件。名为 archive.txt 的目录也能匹配 *.txt，只想处理普通文件时还需要判断类型。普通星号不会越过斜杠，默认也不匹配名字开头的点；需要隐藏文件时，应明确使用相应模式或开启 dotglob。遍历整棵目录树是另一个需求，不能把当前目录的一次展开误认为递归搜索。

环境变量也能改变结果集合。Bash 中非空的 GLOBIGNORE 会过滤匹配结果，并且产生开启 dotglob 的副作用。因此，从交互会话继承状态的脚本可能意外纳入隐藏文件。下面的实验会清除 GLOBIGNORE 及较新版本的排序覆盖变量 GLOBSORT，并明确指定相关选项，让断言对应一套可重复的环境，而不是依赖读者终端的偶然配置。

坏掉的样子

默认情况下，没有匹配结果的模式会保留为原文。因此，遍历 *.png 的循环可能仍然运行一次，变量内容就是一个并不存在的星号文件名。开启 nullglob 后，未匹配的模式会直接消失，但这也可能让接收方变成零文件参数调用。某些程序此时等待标准输入，另一些程序则使用默认目标。未定义变量检查和管道失败检查都不能证明通配符至少找到了一个文件。

对于允许为空的输入，可以在开启 nullglob 后先收集到 Bash 数组，检查元素数量，再决定是否调用消费者。对于必须存在的输入，failglob 会在未匹配时报告展开错误，并阻止该命令执行。如果只想临时改变行为，把选项修改放在子 shell 中，避免影响调用者的后续命令。交互终端的启动文件可能已经修改选项，所以终端上一次成功不能替代脚本自己的前置条件。

以连字符开头的文件名还有另一类风险：接收程序可能将它当作选项。使用 ./*.txt 给结果添加目录前缀，能够避免这种名字直接位于参数开头；程序支持时，还应使用其文档规定的 -- 终止选项解析。引号保留参数边界，却不会关闭目标程序的选项解析。枚举和使用文件也不是原子操作，匹配之后文件仍可能被删除或替换，后续读取必须按照实际结果处理失败。

快速验证

下面的完整代码块需要 Bash 和常见临时目录工具。它自行创建测试目录，分别验证空格文件名、字面模式、未匹配策略和隐藏文件，退出时只删除自己的测试目录。不需要提前准备文件，也不会对当前目录已有文本文件执行操作。

bash --noprofile --norc <<'BASH'
set -e
export LC_ALL=C
set +f
unset GLOBIGNORE GLOBSORT
shopt -u nullglob failglob dotglob
work=$(mktemp -d)
trap 'rm -rf -- "$work"' EXIT
cd "$work"
touch -- a.txt 'two words.txt' .hidden.txt -option.txt
files=(./*.txt)
[[ ${#files[@]} -eq 3 ]]
[[ ${files[2]} == './two words.txt' ]]
printf 'match <%s>\n' "${files[@]}"
literal=('*.txt')
[[ ${literal[0]} == '*.txt' ]]
missing=(./*.missing)
[[ ${missing[0]} == './*.missing' ]]
shopt -s nullglob
missing=(./*.missing)
[[ ${#missing[@]} -eq 0 ]]
if (shopt -s failglob; printf '%s\n' ./*.missing) 2>/dev/null; then
 printf 'unexpected match\n' >&2
 exit 1
fi
shopt -s dotglob
files=(./*.txt)
[[ ${#files[@]} -eq 4 ]]
printf 'PASS: spaces, literal, no-match policies, hidden file\n'
BASH

预期先输出三行匹配结果，其中含空格的文件名完整地处于一行，最后输出通过信息。最初数组没有隐藏文件，开启 dotglob 后才变成四项。触发 failglob 的子 shell 失败属于预期结果，不能执行到打印文件名的命令；如果它反而成功，外层会明确报错退出。这些断言检查的是 Bash 展开和参数保留行为，不能代替接收程序对零参数、目录或选项的语义验证。把示例中的无害打印替换成真实操作前，还应检查该程序的输入契约。

来源

GNU Bash：文件名展开，匹配规则和未匹配选项，已核验 2026-09-06。
GNU Bash：Shell 展开，展开顺序与参数数量变化，已核验 2026-09-06。
GNU Bash：数组，收集匹配结果与保留元素边界，已核验 2026-09-06。

shell 找不到那条裸命令时

Thu, 20 May 2027 00:00:00 +0000

“找不到命令”说明一次查找失败，却不代表 Shell 每次都遍历了 PATH 的全部目录。在普通 Bash 中，不带斜杠的命令词可能对应函数、内建命令、缓存的可执行路径，或者刚刚搜索到的程序。更早的输入读取阶段，别名还可能已经改写命令。面对报错，应先检查真正发生故障的那个 Shell，而不是立即重装一个其实已经存在的工具。

先确认是哪一层查找给出结果

展开之后，Bash 先检查函数，再检查内建命令，之后才查找外部程序。type name 描述当前解析结果，type -a name 可以看到其他定义或候选项。command -v name 适合检查该 Shell 中是否存在某个命令，但结果不保证是文件路径，也可能说明它是函数或内建命令。因此不能无条件把输出交给复制文件或读取文件的工具。

查找外部程序时，PATH 中的目录按顺序参与搜索，靠前的旧版本可以遮住后面的新版本。Bash 还会缓存成功找到的路径：hash -t name 可以检查缓存项，hash -r 清空缓存表。原路径上的文件发生变化，与缓存仍选择旧位置，是两个不同的问题。另开一个终端可能重置这些状态，让故障暂时消失，却没有解释原会话到底发生了什么。

斜杠直接选择路径

命令词中的任何斜杠都会绕过外部程序的 PATH 搜索。./tool 指向当前目录的文件，/opt/example/bin/tool 则指定绝对位置。单独输入 tool 并不自动包含当前目录；只有空目录项、相对目录项等配置才可能让当前工作目录介入搜索。这意味着相同的命令名，在不同目录下也可能选中不同的可执行文件。

给服务配置环境时，应明确列出可信目录。交互终端能运行，不证明定时任务、服务管理器或另一个用户拥有相同的环境和启动文件。排查时需要比较实际环境与工作目录。修改登录配置文件也不会自动更新已经运行的进程；应该把预期环境应用到真正负责启动命令的进程，再验证原来的调用链。

坏掉的样子

Bash 通常在找不到命令时返回 127，在找到却无法执行时返回 126。这两个值可以引导调查，却不能取代诊断文本：脚本文件明明存在，但首行指定的解释器不存在，同样可能执行失败。应同时检查选中的文件、执行权限与解释器，而不是反复向搜索路径追加目录，最后把问题掩盖成一次偶然成功。

也不要为了让名称被找到，就把可写的项目目录插到可信工具之前，或者不加区分地提高权限。先确认函数、别名或缓存是否参与了解析。Bash 的 command name 可以绕过同名函数，明确的可执行路径可以绕过目录选择；这些做法不会自动让程序变得可信，也不能补齐程序自身缺失的依赖。找到命令与命令正确执行，是需要分别验证的两件事。

快速验证

下面的 Bash 实验创建两个同名的临时程序。只有这两个专用临时目录被加入搜索路径，全部环境变化都局限于子 Shell。退出时逐个删除实验创建的文件和目录，不修改任何已安装程序。故意执行失败的分支会立即记录状态，避免被随后的输出操作覆盖。

准备阶段启用遇错退出，让临时文件创建失败时及时停止；开始故意制造执行失败之前，再关闭该选项。本轮在 Bash 5.2.37 上观察到文档规定的一百二十六与一百二十七。对于裸名称搜索失败，命令未找到处理函数可以提供自己的退出状态；下面故意缺失的路径含有斜杠，不会测试这一钩子。因此仍应把状态与实际执行路径、Shell 选项及诊断一起解释，而不能根据一个数字推断所有启动环境。

bash --noprofile --norc <<'BASH'
set -eu
demo_dir=$(mktemp -d)
trap 'rm -f "$demo_dir/one/demo-tool" "$demo_dir/two/demo-tool" "$demo_dir/blocked"; rmdir "$demo_dir/one" "$demo_dir/two" "$demo_dir"' EXIT
mkdir "$demo_dir/one" "$demo_dir/two"
printf '#!/bin/sh\nprintf "one\\n"\n' > "$demo_dir/one/demo-tool"
printf '#!/bin/sh\nprintf "two\\n"\n' > "$demo_dir/two/demo-tool"
chmod +x "$demo_dir/one/demo-tool" "$demo_dir/two/demo-tool"
PATH="$demo_dir/one:$demo_dir/two:$PATH"
demo-tool
hash -p "$demo_dir/two/demo-tool" demo-tool
demo-tool
hash -r
demo-tool
demo-tool() { printf 'function\n'; }
demo-tool
command demo-tool
unset -f demo-tool
"$demo_dir/two/demo-tool"
: > "$demo_dir/blocked"
chmod 600 "$demo_dir/blocked"
set +e
if "$demo_dir/blocked" 2>/dev/null; then
 printf 'unexpected execution\n'
else
 printf 'not-executable=%s\n' "$?"
fi
if "$demo_dir/missing" 2>/dev/null; then
 printf 'unexpected file\n'
else
 printf 'missing=%s\n' "$?"
fi
BASH

开头应依次出现 one、two、one，分别证明普通搜索、显式设置缓存项，以及清缓存后的重新搜索。随后是 function、one、two，区分函数调用、绕过函数和指定绝对路径。最后，不可执行的文件应返回 126，不存在的路径应返回 127。这些结果来自受控的临时文件，不依赖机器恰好安装了哪些同名软件。

实验并没有覆盖所有操作系统加载器错误，也没有模拟每一种服务启动环境。处理实际故障时，应在出错环境中记录解析到的命令与版本，修正后仍沿同一条调用链复验。另一个终端里查询成功，只能证明那个终端可用，不能证明原来的服务已经恢复。

来源

POSIX shell 命令查找，定义了 PATH 查找规则与找不到命令时的退出状态，已核验 2026-06-01。
Bash 参考手册：命令查找与执行，函数和内建命令优先级及可执行路径缓存，已核验 2026-09-07。

$@ 等特殊变量给出函数的完整入参清单

Fri, 16 Apr 2027 00:00:00 +0000

包装脚本应当把收到的参数按原有边界继续传递。在 Bash 的命令参数位置，"$@" 会让每个位置参数分别成为一个带引号的词，因此能保留空值、空格、换行和字面通配符。只用两个简单文件名测试成功，并不能证明包装脚本正确；一旦它把参数列表拼成字符串再拆开，真实调用者传入的边界就可能丢失。转发是否可靠，应当用能暴露这种差异的输入来验证。

参数列表与拼接文本不同

位置参数属于当前脚本或正在执行的函数。$# 返回参数数量，内容为空字符串的参数也计算在内。"$1" 读取第一个参数，"${10}" 读取第十个；后者需要花括号，以区别于第一个参数后面接字符零的写法。$0 表示启动的 shell 或脚本名称，不会作为额外元素出现在 "$@" 中，不能把它误算进业务参数列表。

在普通命令边界上，"$@" 为每个参数保留一个独立词；完全没有位置参数时，它不产生任何参数。相比之下，"$*" 始终形成一个字符串，用 IFS 的第一个字符连接各个值。IFS 未设置时使用空格，设为空字符串时则不插入分隔符。它并不会删除参数内部原有的空格，但各参数原来的边界通常已经无法恢复，因此不适合转发任意列表。

省略引号的 $@ 不是等价简写，展开后的内容仍可能被分词和文件名展开处理。调用者传入的字面星号，到了包装脚本所在目录可能突然匹配出一组文件。往拼接文本里补引号字符也不能恢复结构。需要把列表保存到之后使用时，在 Bash 中写成 args=("$@")，并通过 "${args[@]}" 转发，即使随后调整位置参数，保存的列表仍保留各个元素。

坏掉的样子

函数执行期间拥有自己的位置参数列表。调用时传入的参数暂时替换当前可见列表，返回时恢复调用者的列表。函数内部使用 set 或 shift 修改的是这次函数调用的参数，但这不代表其他所有 shell 状态都自动局部化。例如，没有局部声明就修改 IFS，可能影响调用者之后的命令。参数作用域和普通变量作用域应分别理解，不能互相推导。

Shift 会删除前面的若干参数，并对剩余参数重新编号。解析选项时，必须先确认剩余参数足够，再消费选项及其值；要求删除的数量超过现有参数时会失败。仅检查当前数量大于零，还不足以处理需要额外值的选项。如果之后的错误提示或转发还需要被消费的原始值，应在开始解析前保存数组，避免试图从拼接日志中重新恢复。

引号也不能阻止接收程序把完整参数解释为选项。例如，文件名恰好为 --help 时，"$@" 会完整保留它，但目标工具仍可能显示帮助而不读取文件。传入操作数时，应使用工具文档规定的选项终止符，或适当添加路径前缀。包装脚本必须明确自己的选项在哪里结束，以及哪些剩余参数仍是下游命令的选项，不能不加区分地自动插入分隔符。

诊断时应显示参数数量，并逐项打印。用 "$*" 拼成一行，容易让零参数、一个空参数和包含分隔符的参数看起来相同。Bash printf 的 %q 格式可以帮助观察不明显的字符和边界，但记录日志与转发参数承担不同职责。真正执行时应继续使用保存的列表，不应把日志行重新解释为命令，否则又引入一次解析并失去原有保障。

快速验证

下面的完整代码块构造四项参数，分别为空字符串、带空格的文件名、字面星号模式和看起来像选项的值。随后检查函数参数作用域、零参数时两种引用展开的差异，以及越界 shift 的返回结果。实验只需要 Bash，不需要预先准备文件或启动外部服务。

bash --noprofile --norc <<'BASH'
set -e
IFS=$' \t\n'
set -- '' 'report final.md' '*.log' '--help'
saved=("$@")
verify() {
 [[ $# -eq 4 && $1 == '' && $2 == 'report final.md' ]]
 [[ $3 == '*.log' && $4 == '--help' ]]
 printf 'arg <%q>\n' "$@"
}
verify "${saved[@]}"
consume() {
 [[ $# -eq 2 ]]
 shift
 [[ $# -eq 1 && $1 == child-two ]]
 set -- replaced
 [[ $1 == replaced ]]
}
consume child-one child-two
[[ $# -eq 4 && $2 == 'report final.md' ]]
joined=$(IFS=,; printf '%s' "$*")
[[ $joined == ',report final.md,*.log,--help' ]]
count() { printf '%s' "$#"; }
set --
[[ $(count "$@") == 0 ]]
[[ $(count "$*") == 1 ]]
set -- sole
if shift 2; then
 printf 'unexpected shift success\n' >&2
 exit 1
fi
[[ $# -eq 1 && $1 == sole ]]
printf 'PASS: forwarding, function scope, empty list, shift limit\n'
BASH

预期先输出四行转义后的参数，最后输出通过信息。第一项应明确为空，星号保持字面意义。consume 函数返回后，外层仍应拥有原来的四个参数，而不是函数内部修改后的列表。对仅剩一个参数的列表执行删除两项应失败，并保留原参数。这些断言验证的是参数传输机制；真实包装脚本仍需针对自己的选项语法、必填值和下游调用方式进行验证，不能把机制测试当作所有命令行协议都正确的证明。

来源

GNU Bash：特殊参数，位置参数展开、拼接和计数，已核验 2026-09-06。
GNU Bash：数组，保存和转发独立元素，已核验 2026-09-06。
GNU Bash：分词，未引用展开与空参数，已核验 2026-09-06。

退出码是用一个数字汇报成败

Sat, 27 Mar 2027 00:00:00 +0000

退出状态是 shell 用来决定下一步执行什么的小整数。对 shell 控制流来说，零表示成功，非零进入失败分支，但这并不意味着每个数字都有统一的业务含义。搜索没有匹配、输入格式错误和服务器不可用，都可能返回非零，却需要不同处理。决定重试、忽略或终止之前，应先阅读目标命令的契约。不能只因为状态不为零，就把所有结果归为同一种事故。

让状态始终对应原来的命令

Bash 通过 $? 提供最近前台命令的状态。需要保留时，必须在记录日志、执行另一个条件判断或清理操作之前保存；这些操作也有自己的状态，会覆盖原本想观察的证据。函数通常使用最后执行的命令状态作为返回值，因此，末尾一句成功的日志输出就可能把前面的失败包装成整个函数成功，调用者看到的结果与实际工作脱节。

当命令成功与否决定后续动作时，可以使用 if command; then ... else ... fi。如果需要精确退出码，在 else 分支第一步保存 $?，输出诊断或清理后再通过 return 或 exit 显式传播。不要写成 if ! command，却期待进入成功分支后的 $? 仍然是原始失败码：逻辑取反已经把非零结果转换成成功，数值含义在这里发生了变化。

Bash 在找不到命令时使用一百二十七，找到却无法执行时使用一百二十六。因致命信号终止时，它使用一百二十八加信号编号的约定。这些规则有助于理解 shell 的报告，但应用也可以主动返回相同数字。因此，只有一个状态值还不足以证明内部具体发生了哪件事；应同时保留失败操作的身份和标准错误信息，避免根据数字臆造故障原因。

坏掉的样子

管道默认使用最后一段的退出状态。上游生成器失败时，下游仍可能成功读取一个空流或不完整数据，从而让整体看起来成功。开启 pipefail 后，Bash 返回从左到右最靠右的非零状态；全部成功才为零。PIPESTATUS 能提供每一段的结果，但后续命令同样会覆盖这个数组，所以必须先完整保存观察结果，再进行打印或判断。

set -e 开启的 errexit 具有由语法和调用上下文决定的例外。作为 if 条件的失败、与或列表中的部分命令，以及其他文档规定的场景，都不会自动结束脚本。函数被用作条件时，函数体中的失败命令之后也可能继续执行。ERR trap 也有类似排除规则，并不是每次失败都会产生的通知机制。两者都不能证明整个脚本已经可靠处理所有错误。

大范围追加 || true 会丢掉有用区别。只有该操作所有失败都可接受时，这种写法才表达了真实需求；否则，它可能一起吞掉权限错误或命令不存在等意外问题。应单独处理文档规定的预期结果，并继续传播其他失败。另外，first && second || recover 会在 second 失败时执行 recover，它并不等同于只判断 first 的 if 语句，清理逻辑不能建立在这个错误等价关系上。

后台任务还存在启动与完成之间的边界。成功启动并不表示任务最终成功，应立即保存 $! 中的任务标识，并检查等待该任务时 wait 返回的状态。如果启动多项必需工作，就应分别保留标识并收集结果，否则最后一条成功的前台命令可能掩盖已经在后台失败的工作。返回给调用者的状态应对应业务所需的全部完成条件。

快速验证

下面完整的 Bash 实验主动构造失败，并断言状态如何传播。它检查即时保存、逻辑取反、被当作条件调用的函数，以及启动后失败的后台任务。不需要准备文件，也不会访问外部服务；其中的非零结果是有意安排的测试输入。

bash --noprofile --norc <<'BASH'
set -e
fail_seven() { return 7; }
if fail_seven; then
 exit 1
else
 saved=$?
fi
printf 'saved status %s\n' "$saved"
[[ $saved -eq 7 ]]
[[ $? -eq 0 ]]
if ! fail_seven; then
 negated=$?
fi
[[ $negated -eq 0 ]]
continued=no
conditional_function() {
 false
 continued=yes
}
if conditional_function; then
 [[ $continued == yes ]]
else
 exit 1
fi
(exit 6) &
job_pid=$!
if wait "$job_pid"; then
 exit 1
else
 job_status=$?
fi
[[ $job_status -eq 6 ]]
printf 'PASS: saved failure, negation, conditional context, wait\n'
BASH

预期首先打印保存的退出码七，然后出现通过提示。取反后的状态应为零；即使开启 errexit，条件函数仍然执行到修改变量的语句；wait 则应报告子任务的退出码六。这些断言揭示控制流的边界，不会替任意工具定义状态码含义。实际采用时，还应分别测试预期的否定结果和意外运行错误，并确认包装脚本最终向调用者返回了真正需要的结果，而不是最后一次打印或清理的偶然状态。

来源

GNU Bash：退出状态，shell 状态约定，已核验 2026-09-06。
GNU Bash：Set 内建命令，errexit 的排除场景，已核验 2026-09-06。
GNU Bash：管道，管道整体状态规则，已核验 2026-09-06。

Shell 函数像脚本一样读取自己的参数

Tue, 16 Mar 2027 00:00:00 +0000

Shell 函数把一组命令组织到同一个名称之下，并接收本次调用自己的位置参数。普通调用时，函数体在当前 Shell 中执行，不会自动启动独立进程。这方便复用操作，也意味着赋值、切换目录及其他 Shell 状态变化可能影响调用方。函数接口除了规定输入，还应明确输出、退出状态和有意产生的副作用，不能只因为把几行命令包进了函数，就认为它们已经与外层隔离。

每次调用都有自己的参数列表

调用 demo_func first second 后，这次函数内部的前两个位置分别是传入的两个值，参数数量为二。再次调用其他函数，会暂时安装下一层自己的参数列表；返回后，调用者的列表重新可见。因此，在被调用函数中移位，不会消耗调用者的位置参数。Bash 的 $0 也不会因此变成当前函数名称，不能用它判断自己正在哪个函数里面。

使用 "$@" 转发整份列表，才能保留空参数、空格以及通配符字符各自的边界。应先检查数量，再读取必需的位置，同时区分省略参数与明确传入空字符串。Shell 函数没有自动执行这些规则的参数声明，调用时语法上能写出一串值，并不意味着这些值已经满足函数的业务约定。

局部变量使用动态作用域

Bash 的局部声明会创建一个变量，遮住外层的同名绑定；函数返回之后，原来的绑定再次可见。若修改调用者变量并不是接口的一部分，应为临时值、循环计数器等声明局部变量。面向多个解释器的可移植脚本，不能假设每个 Shell 都实现了 Bash 的这套局部变量设施，解释器要求必须与使用的语法保持一致。

但 Bash 采用动态作用域：被另一个函数调用的函数，可以看到调用者已经声明的局部变量。如果它没有声明自己的局部变量，就直接给同名变量赋值，修改的可能正是调用者的局部绑定。最外层的全局值依然受保护，但中间那层函数的值已经改变。因此，局部变量不是其他函数完全不能接触的词法私有对象，沿真实调用链测试才看得见这种影响。

普通的局部变量声明不会自动恢复工作目录、Shell 选项、陷阱，或函数体已经改写的文件。Bash 另外提供 local -，可以在函数返回时恢复通过 set 改动的选项；这是一项明确的选项作用域机制，与单纯声明临时变量不同。这些效果都需要各自的约定。如果把函数放进普通命令替换，它会在子 Shell 环境中运行，变量和目录变化不会回到外层，但文件写入仍可能保留。捕获输出改变的是执行边界，不是为任意操作提供一套安全沙箱。

状态与数据走不同通道

没有显式返回时，函数通常采用最后执行命令的状态。标准输出应承载约定的数据，诊断则写到标准错误。return 7 把一个状态交给调用者，不是返回文本数字作为数据；exit 会结束正在执行的 Shell，而不只是离开当前函数。设计辅助函数时，需要让调用者知道究竟应读取哪个通道，以及失败后还能不能使用已经打印出的部分结果。

当生产者退出状态重要时，把局部声明与命令替换赋值分开。写成 local result=$(producer) 时，观察到的是声明内建命令的状态，它可能掩盖生产者失败；先声明，再单独赋值，赋值语句才能反映命令替换的状态。之后仍需在日志或清理覆盖它之前保存。把两句合成一行虽然简短，却可能改变错误传播，不能当作纯粹的排版差异。

坏掉的样子

没有局部声明的计数器可能破坏调用者的循环，即便调用者已经把自己的计数器声明为局部也一样。测试辅助函数时，应既从顶层调用，也从另一层函数调用；只检查全局值是否恢复，会漏掉动态作用域影响。同样，标准输出上意外出现的进度消息，会污染原本只捕获一个路径或值的调用方，测试应检查实际捕获结果而不只是看屏幕。

不要依赖错误即退出选项，认为函数内每次失败都会可预测地停下。它受调用上下文影响：被用作条件的函数，体内某条命令失败之后仍可能继续执行。对于失败后必须停止后续工作的操作，应明确检查结果，并在诊断之后传播约定的状态。函数的返回值要代表其契约要求的工作结果，而不是最后一条成功打印语句的偶然状态。

快速验证

在 Bash 中运行下面完整代码块。它只在新 Shell 内修改变量和位置参数，不改变外层终端，也不操作文件。第一个工作函数有意改写调用者的局部变量；第二个函数验证空参数、带空格参数、移位和非零返回；最后两个函数比较合并声明与独立赋值的状态差异。这样可以分别观察作用域、参数边界和失败传播，而不把它们混成一次笼统的成功测试。

BASH_ENV= bash --noprofile --norc <<'BASH'
demo_value=global
demo_worker() { demo_value=changed; }
demo_scope() {
 local demo_value=inner
 printf 'local-before=%s\n' "$demo_value"
 demo_worker
 printf 'local-after=%s\n' "$demo_value"
}
demo_scope
printf 'global-after=%s\n' "$demo_value"
demo_args() {
 local demo_arg
 printf 'function-count=%s\n' "$#"
 for demo_arg in "$@"; do printf 'argument=<%s>\n' "$demo_arg"; done
 shift
 printf 'after-shift=%s\n' "$#"
 return 7
}
set -- outer-one outer-two
if demo_args '' 'two words'; then
 exit 99
else
 demo_status=$?
fi
printf 'function-status=%s outer-count=%s outer-first=%s\n' "$demo_status" "$#" "$1"
demo_masked() { local demo_result=$(return 9); }
demo_checked() {
 local demo_result
 demo_result=$(return 9)
}
demo_masked
printf 'combined-declaration=%s\n' "$?"
if demo_checked; then exit 99; else printf 'separate-assignment=%s\n' "$?"; fi
BASH

局部值应从 inner 变成 changed，但全局值仍是 global。两个传入参数应分别打印，其中一个为空；函数移位后返回七，外层依然持有两个参数，第一个仍是 outer-one。最后，合并声明报告零，独立赋值报告九。这些结果验证真实调用边界，也揭示局部声明能够保护什么、不能保护什么，避免把“变量叫局部”误当成完全隔离的证据。

来源

Bash Shell 函数，函数参数列表及动态变量作用域，已核验 2026-09-07。
Bash 专用内建命令，局部声明行为及其返回状态，已核验 2026-09-07。
Bash set 内建命令，函数作为条件时的错误即退出语义，已核验 2026-09-07。

命令替换把一条命令的输出嵌进另一行

Wed, 03 Mar 2027 00:00:00 +0000

命令替换会收集一个命令的标准输出，再把得到的文本放入外层表达式。常见的 $(command) 适合获取时间戳、计算出的标签或其他较小的文本值，但它并不是任意字节的透明传输通道，也不是可靠的文件名列表容器。使用前需要理解三个边界：末尾换行如何处理、内部命令在哪个执行环境运行，以及失败状态如何传递。只看到变量里有内容，不能证明整个操作成功。

先收集文本，再决定怎样使用

本文讨论的标准命令替换形式会让 Bash 在子 shell 环境中运行内部命令，收集标准输出，并删除末尾所有换行符。位于文本中间的换行仍然保留。双引号能阻止后续分词和文件名展开，却不能恢复已经删除的尾部换行。如果需要精确保留最后几个字节，应该使用文件或数据流，而不是依靠 shell 变量原样往返。

赋值语句 result=$(producer) 会把处理后的文本存进变量，不在此处拆成多个参数。后续使用时仍应写成 "$result"，保留它的参数边界。类似地，consumer "$(producer)" 会传递一个参数，即使结果为空。去掉引号可能得到多个参数，也可能完全没有参数；输出中的星号还可能匹配当前目录的文件，让同样的生产者输出在不同目录产生不同调用结果。

标准错误和标准输出彼此独立，除非主动重定向，诊断信息仍可能显示在终端，而变量只收集结果正文。将两路输出合并后，警告文本可能污染本应供程序读取的值。因此，应先确定生产者的输出契约，再决定是否合并；直接吞掉所有诊断信息也可能让空结果失去可解释的原因。输出内容、诊断信息和退出状态应分别检查。

不要把这里的作用域结论推广到较新 Bash 的每一种捕获语法。本文使用的美元符号加圆括号形式具有实验验证的子 Shell 行为；较新的当前环境捕获形式会保留不同的副作用。说明一个捕获值时，应明确语法与解释器版本，而不是把所有能够取得文本的写法都视为等价。

坏掉的样子

子 shell 内修改变量或执行 cd，不会改变调用者对应的变量和工作目录。但文件系统或网络副作用并不会因此消失：在命令替换里创建的文件是真实文件，发出的请求也是真实请求。执行环境隔离不能被误解为事务回滚，也不能保证内部操作没有外部影响。

有输出也不代表生产者成功。仅包含赋值的命令会使用最后一个命令替换的退出状态，因此 if result=$(producer); then 可以检查生产者结果。相反，printf '%s' "$(producer)" 的状态通常来自 printf，而不是内部命令。生产者可以先输出部分内容，再失败退出；应立即保存退出码，并明确失败时是否允许使用这些不完整内容。后面的打印日志命令会覆盖 $? 所指向的最近状态。

多条命令组成的替换尤其需要明确失败传播：前一步失败后，最后一步仍可能成功，从而使整个替换返回成功。重要操作应在生产者内部显式判断，并返回预期状态。函数中如果需要检查捕获赋值的状态，也应把 local 声明和赋值分成两步，避免声明内建命令掩盖生产者退出码。不能仅凭脚本开启了某个全局选项，就假设每种上下文都会按同样方式中止。

命令替换还会在外层命令运行前收集输出，因此不适合无限输出或需要逐步消费的交互数据。不要通过未引用的 find 输出构造任意文件名列表，空白和通配字符会破坏原有路径边界。可以改用 find 的 exec 接口直接传递路径，或者选择明确定义边界的记录协议。是否需要一个文本值，还是一组独立记录，应在选择语法前确定。

快速验证

下面代码块只使用 Bash 内建命令，不需要准备文件或服务。它把输出内容和退出码分别断言，并主动构造退出码为七的失败生产者。这个失败是实验的一部分，整个测试仍必须运行到最后的通过提示，不能把任意非零输出都当成环境故障。

bash --noprofile --norc <<'BASH'
set -e
outer=parent
captured=$(outer=child; printf 'first\nsecond\n\n')
[[ $outer == parent ]]
[[ $captured == $'first\nsecond' ]]
printf 'captured <%q>\n' "$captured"
if partial=$(printf 'incomplete'; exit 7); then
 printf 'unexpected producer success\n' >&2
 exit 1
else
 status=$?
fi
[[ $status -eq 7 && $partial == incomplete ]]
printf 'producer status %s; partial <%s>\n' "$status" "$partial"
printf '%s' "$(exit 9)"
[[ $? -eq 0 ]]
IFS=$' \t\n'
set -- "$(printf 'two words\n')"
[[ $# -eq 1 && $1 == 'two words' ]]
set -- "$(printf '\n\n')"
[[ $# -eq 1 && $1 == '' ]]
printf 'PASS: capture, subshell scope, failure status, empty result\n'
BASH

第一行以转义形式显示捕获值，应该只包含正文中间的一个换行，没有尾部换行。下一行同时显示退出码七和部分输出，证明失败状态与非空正文可以同时存在。之后外层 printf 成功的断言说明，只检查消费者状态会漏掉生产者失败。最后还检查了空结果在引号内形成一个空参数。这些实验验证的是文中几个小型同步生产者的行为；真实命令若存在耗时、输出格式或错误语义要求，仍应分别验证这些契约。

来源

GNU Bash：命令替换，标准替换形式的执行环境和换行处理，已核验 2026-09-06。
GNU Bash：分词，未引用捕获结果的处理，已核验 2026-09-06。
GNU Bash：特殊参数，问号参数提供的最近退出状态，已核验 2026-09-06。

Here-string 提供文本并追加换行

Mon, 15 Feb 2027 00:00:00 +0000

Bash 的 here-string 会把一个词展开后的值送给命令的标准输入，并在末尾追加一个换行符。当变量里已经有少量文本，而目标程序从标准输入读取时，这种写法很方便。它省掉了额外的打印命令，但并不保证输入与变量逐字节相同，也不承诺内部一定使用内存、管道或文件。判断是否适用，应看接收方需要什么输入，而不是只比较命令行长度。

接收命令读取之前先完成展开

三个小于号之后的词可以包含变量展开、算术展开和命令替换，因此不一定是字面常量。单引号保留源码中的字面文本，双引号则允许通常的变量和命令展开。通过变量展开得到的字符串，即使包含美元符号和括号，也不会仅因出现在 here-string 中就被再次作为 shell 命令执行。源码中明确写出的替换语法与变量保存的数据必须区分。

当前 Bash 不会对 here-string 的词执行分词或文件名展开，而是把结果作为一个字符串交付。这里引用变量仍能清楚表达意图，但不能把这种重定向上下文和普通命令参数位置混为一谈。后者使用未引用变量时仍可能按空白拆分，或把星号变成文件名。因此，某个值通过 here-string 正常到达，并不能证明在别处省略引号也安全。

末尾追加换行是无条件发生的。原值没有换行时会多一个，原值已经有尾部换行时还会再多一个。空变量也因此产生包含一个换行字节的输入，而不是立即结束的零字节输入。对于按行处理的工具，这常常符合需求；对于严格长度、签名字节或特定结束字符的协议，则可能直接改变意义，不能把它当作原始字节透传方式。

坏掉的样子

Shell 形成输入后，read 还会按自己的规则解释。默认分词可能移除首尾 IFS 空白，反斜杠也可能作为转义符处理。读取需要保留空格和反斜杠的一行时，应使用 IFS= read -r name。它保护的是这一行的内容；单次 read 仍然在第一个换行处结束，并不会自动把任意多行字符串全部装进变量。输入构造规则与消费者解析规则是两个阶段。

带重定向的内建命令或循环可以在当前 shell 中运行，因此其中的赋值能够在后续代码中继续使用。相比把循环放进管道，这有助于避免 Bash 通常为管道阶段创建子 shell 导致的状态丢失。重定向本身不会包上一层子 shell，但如果表达式的其他地方明确使用子 shell 或命令替换，它们仍然具有通常的作用域与副作用，不能因为用了 here-string 就忽略。

源码没有显式文件名，并不能证明 Bash 内部没有使用文件或其他存储方式。程序不应依赖标准输入可寻址、具有固定缓冲容量，或绝不产生临时后端存储。对于已经存在的大文件，直接文件重定向能避免先把全部内容收集进变量。如果需要不追加换行的精确文本，可以使用格式明确的 printf 或文件输入，仍应通过接收方实际读到的字节验证结果。

Here-string 还是特定 shell 的语法功能，并非所有名为 sh 的解释器都支持。使用它的脚本应选择支持该功能的解释器，测试时也应明确调用同一个解释器。把 echo 管道机械替换为 here-string，可能同时改变换行和变量作用域，不能只当作外观不同的等价写法。应该比较输入字节、记录数量和状态变化，确认真实调用链仍符合需求。

快速验证

下面的完整实验需要 Bash 和 Python 三。Python 将标准输入显示成十六进制，使额外的换行字节清晰可见；随后捕获的是十六进制文本，所以命令替换删除其末尾换行并不会丢失被检查的原始输入信息。其他断言使用 read 和带重定向的循环验证空白、字面文本与多行读取，不需要创建测试文件。

bash --noprofile --norc <<'BASH'
set -e
hex_input() {
 python3 -c 'import sys; print(sys.stdin.buffer.read().hex())'
}
[[ $(hex_input <<< X) == 580a ]]
[[ $(hex_input <<< '') == 0a ]]
[[ $(hex_input <<< $'X\n') == 580a0a ]]
[[ $(printf '%s' X | hex_input) == 58 ]]
value=' a\b *.txt '
IFS= read -r received <<< "$value"
[[ $received == "$value" ]]
literal='$(printf injected)'
IFS= read -r received <<< "$literal"
[[ $received == '$(printf injected)' ]]
value=$'one\ntwo'
IFS= read -r first <<< "$value"
[[ $first == one ]]
lines=0
while IFS= read -r line; do
 lines=$((lines + 1))
done <<< "$value"
[[ $lines -eq 2 ]]
printf 'PASS: newline bytes, preserved text, single read, loop scope\n'
BASH

预期只输出最后的通过信息。十六进制断言明确区分一个换行和两个换行，并与不添加换行的 printf 比较。看起来像命令的字面字符串必须保持原文，循环计数也应保留在外层 shell 中。这些结果验证文档规定的输入行为，没有检查内部存储机制。改用其他消费者之前，还应确认它自身如何处理空行、多条记录和尾部空白，不能把 read 的观察直接推广到所有程序。

来源

GNU Bash：重定向，here-string 展开与追加换行规则，已核验 2026-09-06。
GNU Bash：Bash 内建命令，read 分隔和原始输入模式，已核验 2026-09-06。
GNU Bash：命令替换，捕获输出与尾部换行删除，已核验 2026-09-06。

case 只执行与模式匹配的那一支

Sat, 30 Jan 2027 00:00:00 +0000

Case 语句把一个值依次与一组 shell 模式比较，适合命令分发、有限答案选择或文件名后缀分类。每个分支明确自己处理哪些输入，多个模式也可以共享同一个动作。分支顺序和默认行为都是接口的一部分：输入同时属于多个类别时谁先处理，完全不属于已知类别时是否报错，都需要明确规定。不能只看到成功输入能跑通，就认为整个分发器已经可靠。

模式匹配整个值

Case 使用的是 shell 模式，不是正则表达式。星号匹配任意长度字符串，问号匹配一个字符，方括号描述字符集合或范围。因此，[0-9]* 表示一个数字后面可以跟任意内容，并不表示整串都是数字。若要验证非空十进制文本，可以先拒绝空字符串，以及包含任意非数字字符的字符串，而不必把输入放进算术求值环境。

start|up|run) 这样的多个模式可以共用动作。*.log) 等后缀规则则只是在分类字符串，并不会打开文件或搜索目录。因此，匹配成功不能证明对应文件存在。与普通文件名展开不同，字符串匹配中的斜杠和开头的点也没有相同的特殊排除作用。分类、文件存在性和文件类型是不同判断，真正操作文件前仍应根据需求单独验证。

Bash 会对被测试的词执行文档规定的展开，但不会像普通命令参数那样对它分词或执行文件名展开。因此，这个位置的未引用空变量不会删掉语法上的词，进而把 case 变成语法错误。引用被测试值仍然是清楚的书写习惯。若开启 nounset，则要另外处理未提供的位置参数，或先验证参数数量；引号本身不能让未设置参数变得可用。

实际执行某个分支后，case 返回该分支最后执行命令的状态。因此，匹配成功与动作成功是两件事。下面的实验也让一个已经选中的分支返回六，并检查失败继续向外传播，避免把“找到了正确分支”误报成“分支里的操作已经成功”。

坏掉的样子

使用通常的双分号结束符时，首个匹配分支执行后，case 就结束。精确值应放在宽泛类别前，兜底星号通常放在最后，否则通用选项分支会吞掉后面的精确状态命令。语法检查只能证明结构可解析，不能证明顺序符合业务优先级。应该构造同时匹配两个规则的输入，并断言实际执行哪个动作，才能发现被遮蔽的分支。

如果没有任何模式匹配，case 不执行动作，却仍然返回零。因此，没有默认分支不等于会自动报错。命令分发器若要求拒绝未知命令，就必须在默认分支明确报告并返回失败；可选分类逻辑则可能有意允许不匹配。这个策略来自调用契约，不能假设 case 自带完整输入校验，更不能依赖自动退出选项补足业务含义。

模式上的引号也会改变含义。"*.log" 匹配字面字符，而不引用的写法匹配整个后缀类别。变量提供模式时同样需要区分：它究竟是受控的匹配表达式，还是应该精确比较的普通文本。不要让一个本来只是标识符的值意外获得通配能力，也不要为了“所有东西都加引号”而破坏本来需要的模式语义。

选项和版本还会改变行为。Nocasematch 控制是否忽略大小写；扩展模式要求在相关代码被解析之前开启 extglob。较新 Bash 还提供继续执行或继续匹配的其他分支结束符，它们不同于双分号，也不一定能在旧 shell 上运行。下面实验刻意只使用普通模式和双分号，保持 Bash 三点二兼容语法，本轮实际使用 Bash 五点二运行，避免把可选语法混入基本规则。

快速验证

下面完整代码包含精确命令、别名组、通配类别、空输入错误和未知输入错误。第二个函数验证十进制文本，不会把数字开头但后面含字母的值放过。断言同时检查正常输出与错误码，而不是仅观察整个脚本最后有没有非零退出。

bash --noprofile --norc <<'BASH'
set -e
export LC_ALL=C
shopt -u nocasematch
route() {
 case "${1-}" in
 status|--status) printf '%s' status ;;
 start|up|run) printf '%s' start ;;
 '') return 2 ;;
 --*) return 3 ;;
 *.log) printf '%s' log ;;
 *) return 4 ;;
 esac
}
[[ $(route --status) == status ]]
[[ $(route up) == start ]]
[[ $(route 'report final.log') == log ]]
expect_error() {
 local expected=$1
 shift
 if route "$@"; then
 return 1
 else
 local actual=$?
 [[ $actual -eq $expected ]]
 fi
}
expect_error 2 ''
expect_error 2
expect_error 3 --unknown
expect_error 4 STATUS
digits() {
 case "${1-}" in
 ''|*[!0-9]*) return 1 ;;
 *) return 0 ;;
 esac
}
digits 007
if digits 7abc; then exit 1; fi
if digits ''; then exit 1; fi
empty=''
matched=no
case $empty in '') matched=yes ;; esac
[[ $matched == yes ]]
case unmatched in known) exit 1 ;; esac
[[ $? -eq 0 ]]
if case match in match) (exit 6) ;; esac; then
 exit 1
else
 [[ $? -eq 6 ]]
fi
printf 'PASS: precedence, aliases, empty input, validation, no match\n'
BASH

预期只输出最后的通过提示，没有其他正文。精确的状态选项必须优先于通用未知选项分支；由于实验关闭了忽略大小写，大写 STATUS 应当被拒绝。末尾的检查还证明，展开为空的被测试词语法有效，以及完全没有模式匹配时 case 会成功返回。这些断言只验证分发选择；把无害打印换成真实动作后，还需要独立检查参数、外部副作用和失败传播，不能把选中了正确分支等同于操作已经成功。

来源

GNU Bash：条件结构，case 的顺序、展开和返回状态，已核验 2026-09-06。
GNU Bash：模式匹配，通配符与扩展模式语义，已核验 2026-09-06。
GNU Bash：分词，展开值发生分词的上下文，已核验 2026-09-06。

Shell 的 trap 把信号转成一次清理动作

Tue, 12 Jan 2027 00:00:00 +0000

trap 让 Shell 为某个信号或自身事件安排动作，适合删除临时文件、协调退出，但不会让中断变成原子操作，也无法保证任何终止方式都能完成清理。在 Bash 中，trap 是内建命令，EXIT 是 Shell 事件，而不是操作系统信号。可靠的设计需要明确处理哪些出口，并保留执行为什么结束的证据，不能仅凭注册了一次处理器就断言资源一定会被回收。

信号处理与退出清理分开

trap 'cleanup' INT TERM 会替换这些信号的默认动作。如果处理器只是返回，Shell 可能继续执行；安装处理器并不天然等于启动关停。一种明确的 Bash 写法是在信号处理器中主动退出，再让统一的退出处理器负责清理。正常执行到末尾、显式调用退出命令，也会经过这个出口，从而减少各业务分支之间重复的资源回收逻辑。

从函数或被点命令加载的文件返回，不等于结束整个 Shell。普通执行脚本里的顶层 return 也不是通用退出方式。此外，不能跨 Shell 假定未处理的致命信号一定会触发退出清理。应明确处理准备支持的终止信号，并使用服务真正采用的解释器测试，而不是在交互终端里试过一次便推广到所有启动环境。

trap - INT 恢复默认动作，trap '' INT 则忽略信号，两者策略不同。非交互 Shell 还可能从启动者继承被忽略的信号，而且无法重新捕获或重置，所以启动路径也是行为的一部分。需要确认实际安装的动作时，可以检查 trap -p 输出；配置中写过处理器，与当前 Shell 最终持有什么处理器，仍然需要区分。

保留最初的退出原因

进入退出处理器后，应先保存 $?，避免后面的命令覆盖它。清理末尾固定执行 exit 1，会把成功改成失败，也会抹掉原来不同的错误码。使用保存的状态退出，才能保留触发收尾的原始结果。清理本身失败时仍应输出可见诊断，并制定明确策略，尤其要说明主工作成功而清理失败时最终如何报告，不能把这两种结果混成一句“脚本结束”。

示例为已处理的中断选择一百三十，为终止请求选择一百四十三，沿用 Bash 常见的信号状态约定。但这是处理器主动执行的普通退出，不证明进程真的被操作系统信号直接杀死；使用进程接口的监督程序能够区分两者。短暂清理期间关闭退出陷阱、忽略中断和终止请求，是为了避免这些处理器重入清理逻辑，并不是无限期屏蔽关停的建议。

这段清理代码有意优先保留最初的退出状态。删除命令即使报告错误，也不会改变已保存的结果，因此零退出码不是清理完成的独立证明。若残留资源会产生后果，需要另外测试清理失败，并决定是否报告不同的失败、进行安全重试，或保留恢复所需证据。

坏掉的样子

强制杀死信号无法捕获，停止信号也不能捕获，更不能把停止视作清理机会。断电、崩溃和强制终止都可能留下资源。因此，陷阱不能替代崩溃安全写入、事务更新或单独定义的恢复流程。删除目标必须限制在脚本拥有的路径内；一个尚未初始化完成的变量，绝不能意外变成宽泛删除范围。清理动作的权限边界与正常业务操作同样需要检查。

执行时机也有差别。Bash 等待同步前台命令结束时，可以推迟执行已经捕获的信号处理器；通过内建等待命令等待异步任务时，被捕获的信号则会先打断等待，随后进入处理器。因此，注册陷阱并不意味着任意阻塞操作都能立即响应关停，更不能据此承诺固定的退出时限。长时间外部工作需要结合真实等待方式验证。

终端中的 Ctrl-C 会把中断信号发给前台进程组，而向单个进程编号发送信号只针对那个进程。于是，同一个子进程可能在一种测试中收到信号，在另一种测试中没有收到。管理工作进程的脚本，应分别定义信号转发、等待结束和资源归属；不能杀掉不相关进程，也不能把 Shell 已经退出当作所有后代进程都已停止的证据。

快速验证

使用 Python 3、Bash 及常见 Unix 工具运行下面的示例。每个分支启动一个独立 Bash，并在私有临时目录中创建一个文件；信号只发给这层新 Shell 自身。外层临时目录由 Python 管理，强制终止分支故意留下的文件，最后也由这个外层管理器删除，不会把残留留在用户工作区。

import os
import signal
import subprocess
import tempfile
from pathlib import Path

script = r'''
demo_file=$1
cleanup() {
 demo_status=$?
 trap - EXIT
 trap '' INT TERM
 rm -f -- "$demo_file"
 printf 'cleanup=%s\n' "$demo_status"
 exit "$demo_status"
}
trap cleanup EXIT
trap 'exit 130' INT
trap 'exit 143' TERM
: > "$demo_file" || exit 1
case "$2" in
 normal) exit 7 ;;
 *) kill "-$2" "$$" ;;
esac
exit 99
'''
with tempfile.TemporaryDirectory(prefix="bash-trap-demo-") as directory:
 for mode, expected in [("normal", 7), ("TERM", 143),
 ("INT", 130), ("KILL", -signal.SIGKILL)]:
 target = Path(directory) / mode
 result = subprocess.run(
 ["bash", "--noprofile", "--norc", "-c", script,
 "trap-demo", str(target), mode],
 env=dict(os.environ, BASH_ENV=""),
 text=True, capture_output=True, timeout=5,
 )
 cleaned = result.stdout == f"cleanup={expected}\n"
 remains = target.exists()
 assert result.returncode == expected, result
 assert (cleaned, remains) == (mode != "KILL", mode == "KILL"), result
 assert not result.stderr, result
 print(f"{mode}: rc={result.returncode} cleaned={cleaned} remains={remains}")

前三种情况应分别返回七、一百四十三和一百三十，观察到清理输出，且文件已经不存在。强制杀死分支应得到 Python 表示信号终止的负数返回码，通常为负九，没有清理输出，同时文件仍存在；若由 Shell 调用，通常会把同一终止表示为一百三十七。这种差异来自结果表示方式，不能误判成实验不一致。

这组结果验证了原退出状态得到保留，也验证了无法捕获的终止确实绕过清理。它没有测试向工作进程转发信号、终端前台进程组，或长时间同步命令造成的处理延迟。真实脚本涉及这些行为时，需要补上对应环境中的观察，而不是把这个单进程实验当作整套进程管理机制已经验收。

来源

Bash 信号，等待期间的信号处理及前台进程组，已核验 2026-09-07。
POSIX trap，退出事件、继承的信号处置及陷阱动作，已核验 2026-09-07。

Shell · XB 现场笔记

bash history 是可以搜索的命令日志

会话内存与历史文件不同

追加保存不会自动刷新其他终端

搜索后先检查，再执行

坏掉的样子

快速验证

来源

Shell 的字段拆分把未加引号的变量拆成多个参数

是否分词取决于上下文

坏掉的样子

快速验证

来源

Shell 位置参数是一份有编号的清单

解释含义之前，先保住列表边界

getopts 检查语法，业务规则检查含义

坏掉的样子

快速验证

来源

Shell 参数展开产生替代值

默认值要区分未设置与空字符串

模式处理字符串，不访问文件

坏掉的样子

快速验证

来源

umask 过滤新建权限，默认 ACL 会改变规则

坏掉的样子

快速验证

在正确层级应用创建策略

来源

别名免除重复敲击

替换发生在读取输入时

作用域与生效时机分开看

坏掉的样子

快速验证

延伸阅读

来源

重定向重新安排流向

打开文件本身就可能改变数据

复制记住的是当下的目标

坏掉的样子

快速验证

延伸阅读

来源

管道让进程彼此流式连接

有限容量的字节流

坏掉的样子

快速验证

来源

作业控制在进程组之间交接终端前台

坏掉的样子

快速验证

明确工作寿命和输入来源

来源

环境变量属于各自的进程

导出决定另一个程序能收到什么

子 Shell 不等于重新执行一个 Shell 程序

单次调用配置有自己的生命周期

坏掉的样子

快速验证

来源

Bash 的通配符在命令执行前就展开

先匹配，再保留参数边界

坏掉的样子

快速验证

来源

shell 找不到那条裸命令时

先确认是哪一层查找给出结果

斜杠直接选择路径

坏掉的样子

快速验证

来源

$@ 等特殊变量给出函数的完整入参清单

参数列表与拼接文本不同

坏掉的样子

快速验证

来源

退出码是用一个数字汇报成败

让状态始终对应原来的命令

坏掉的样子