你在 Linux 服务器上排查问题时有没有遇到过这样的场景跑一个脚本输出只在屏幕上滚了一屏就消失想回看却发现什么都没有或者写了一个自动化任务每天定时执行你怀疑它出错了但输出被全部丢弃连一条报错都找不到。更常见的场景是把命令结果写到日志文件里第二天打开一看文件是空的或者只留下了最后一次运行的内容。这些问题十有八九出在重定向的使用上。重定向以及和它绑定在一起的一批 Linux 特殊符号是使用频率极高、又经常被低估的内容。不要觉得“不就是一个和一个吗”真正到生产环境排障时这里的坑一个比一个深有人用把历史日志覆盖丢了有人因为21放错位置导致报错信息始终没有进日志还有人把定时任务的输出直接丢弃出问题时无从查起。这篇文章以 Linux 特殊符号为线索完整拆解输出重定向、追加重定向、错误重定向2、2、21、输入重定向、以及管道|、命令替换$()、逻辑控制符、||等高频符号。读完后你能做到三件事理解每个符号的底层原理写出安全规范的重定向命令在生产环境里快速定位与重定向相关的故障。1. Linux 特殊符号全景图先建立整体认知Shell 之所以强大一个重要原因是它提供了非常丰富的符号体系。这些符号单独看只是一个字符组合到命令里却能改变程序的输入输出方向、控制命令执行顺序、匹配批量文件。可以说Unix/Linux 的设计哲学里“一切皆文件、符号即逻辑”体现在命令行工具链的每一个角落。Linux 特殊符号按用途可以分成几大类第一类是重定向符号负责改变命令的输入来源和输出去向第二类是管道符号负责把多个命令串成流水线第三类是命令替换符号负责把命令的执行结果嵌入到另一条命令里第四类是逻辑控制符负责决定多条命令是否按条件执行第五类是通配符和引用符负责文件名匹配和特殊字符转义。这套符号体系是 Linux 常用命令的高级用法基础也是从“会敲命令”走向“会写脚本”的关键门槛。1.1 高频符号速查表下面这张表把日常最常用到的符号集中列出来建议收藏备用符号名称与含义典型作用输出重定向将标准输出写入文件覆盖原内容追加重定向将标准输出追加到文件末尾输入重定向从文件读取标准输入Here Document将此处文档内容作为标准输入2错误重定向将标准错误写入文件2错误追加将标准错误追加到文件末尾21合并重定向将标准错误指向标准输出当前位置合并输出将标准输出和标准错误一起写入文件|管道符把前一个命令的输出接到后一个命令的输入$()命令替换用命令执行结果替换表达式本身反引号旧式命令替换作用同$();顺序分隔符无条件执行下一条命令逻辑与前一条命令成功才执行后一条||逻辑或前一条命令失败才执行后一条*通配符匹配任意长度字符?通配符匹配单个字符[]字符集匹配指定范围内的单个字符~家目录表示当前用户主目录#注释符注释行Shell 不执行其后的内容$变量引用引用变量值单引号强引用符号内容原样保留双引号弱引用变量和命令替换仍生效\转义符取消下一个字符的特殊含义后台符将命令放入后台执行1.2 按用途理解特殊符号先看重定向符号。Shell 把命令的输出分成标准输出和标准错误两个通道和控制标准输出2和2控制标准错误21把两个通道合并到一起。初学者最容易忽略的一点是报错信息和正常信息默认都打在屏幕上肉眼几乎区分不出来但它们在命令层面是两个完全独立的通道。通道不同重定向的方式就不同这就是很多日志文件“有正常内容却没有错误信息”的根本原因。再看管道符号|。管道负责把两个命令连接起来让前一个命令的输出直接作为后一个命令的输入中间不需要经过临时文件。它和重定向的区别在于重定向的右侧是文件或设备管道的右侧是另一个命令。命令替换$()则把一条命令的结果“变成文字”嵌入到外层命令中最典型的场景是把date的结果拼进文件名。逻辑控制符;、、||解决的是“多条命令按什么顺序执行”的问题。;是无条件顺序执行是前一个成功才继续||是前一个失败才继续。通配符*、?、[]则用于文件名的模式匹配在ls、rm、cp等命令中批量操作文件时非常实用。1.3 最容易混淆的几组符号第一组是和。前者覆盖后者追加这是重定向里最基础也最容易造成事故的区别。命令一旦执行会立刻清空目标文件Shell 不会弹出任何确认提示。第二组是2和21。2是把标准错误单独写到文件21是把标准错误合并到标准输出当前指向的位置。两者经常一起出现但含义完全不同。很多老手写惯了 log 21却不清楚这个写法为什么能同时收集两种输出更不清楚如果把21挪到前面就会失效。第三组是管道符|和逻辑或||。前者是数据通道后者是条件跳转。常在 CSDN 评论区看到有人把||当成管道用其实||的含义是“前一个命令失败了才执行后面的命令”。2. 重定向核心原理三个标准文件描述符理解了符号体系之后需要把重定向的原理彻底搞清楚。在 Linux 里一个进程启动后内核会为它建立三个默认打开的文件描述符它们统一管理着进程的输入来源和输出去向。文件描述符本质上是内核维护的整数编号进程通过这个编号找到对应的文件或设备。2.1 标准输入、标准输出和标准错误文件描述符名称默认指向常用重定向符号0stdin 标准输入键盘、、1stdout 标准输出终端屏幕、、1、12stderr 标准错误终端屏幕2、2、21默认情况下标准输出和标准错误都写到终端屏幕所以新程序员很难区分“普通输出”和“报错输出”。重定向的核心就是把某个文件描述符指向的目标从终端换成文件、设备或者另一个命令。的完整写法其实是1因为标准输出的编号是 1Shell 为了方便日常使用省略了 1的完整写法是0同理省略了 0。2.2 程序为什么需要文件描述符文件描述符可以理解为进程与外部世界之间的“通信端口”。当一个命令执行时它不知道用户是在终端上敲命令还是通过脚本调用它只知道往自己的标准输出写内容。至于这些内容最终到屏幕、到日志文件、还是被丢弃完全由调用方通过重定向决定。这种设计带来的好处是极大的灵活性同一个程序可以在测试时把输出打到屏幕在生产中把输出写进日志程序自身不需要做任何改动。这也是为什么 Linux 高手喜欢说“重定向是命令行的胶水”。它把程序的标准输出和标准错误这两个端口灵活地连接到任意位置。理解了这个模型再看、、2就不再是死记硬背的符号而是对文件描述符目标的重新指定。2.3 一个容易直觉判断错的现象判断标准输出和标准错误有一个很实用的方法管道|只连接标准输出不连接标准错误。如果你执行find / -name *.conf | grep nginxgrep 接收到的只是 find 的标准输出find 因为权限不足产生的报错属于标准错误会直接打在终端屏幕上不会进入 grep 的输入流。这个现象在写脚本时尤其误导人明明加了管道过滤报错信息还是刺眼地冒出来了因为管道根本没有接管标准错误通道。3. 输出重定向 与追加重定向 最常用的两类操作现在进入本文的核心主题输出重定向和追加重定向。这两个符号是日常输入频率最高的重定向形式几乎所有涉及日志、结果保存、脚本输出的场景都会用到。3.1 覆盖重定向的使用示例# 将 ls 的输出保存到文件 ls -l /etc /tmp/etc_info.txt # 查看文件内容 cat /tmp/etc_info.txt执行后ls -l /etc的标准输出不再显示在终端而是写入/tmp/etc_info.txt。如果该文件原本存在内容会被完全清空后写入新内容如果文件不存在Shell 会自动创建。# 再次执行之前的文件内容会被覆盖 echo 第一次写入 /tmp/test.log echo 第二次写入 /tmp/test.log cat /tmp/test.log上面这段命令执行后/tmp/test.log里只有一行内容第二次写入。第一次写入的内容已经被覆盖。的语义是“把文件清空然后写入”这是它与最本质的区别。3.2 追加重定向的使用示例# 多次执行命令使用追加重定向保留完整日志 echo 第一次执行 /tmp/test.log echo 运行时间: $(date) /tmp/test.log echo 第二次执行 /tmp/test.log echo 运行状态: success /tmp/test.log cat /tmp/test.log第一次使用是为了“新建并初始化”日志文件后续的把新内容追加到文件末尾。这种“先建立、后追加”的模式在实际脚本中非常常见。# 追加一个多行内容 cat /tmp/test.log EOF 补充信息 1 补充信息 2 EOF tail -n 5 /tmp/test.log3.3 两者的核心区别对比项覆盖重定向追加重定向操作方式清空原文件后写入保留原内容在末尾追加文件不存在自动创建自动创建适用场景生成新快照、临时结果、每次需要干净输出日志累积、多次执行记录、审计留痕主要风险覆盖已有内容丢失历史数据文件不断增大需配合日志轮转选择原则并不复杂凡是需要留痕的日志类输出优先用只有明确知道“只要最新结果不需要旧内容”时才用。但实际项目里经常有工程师在部署脚本中随手写把部署日志的历史记录覆盖掉导致事后无法回溯。3.4 生产场景中的真实教训备份脚本、部署脚本、定时任务日志这三个地方是最容易踩坑的场景。假设/var/log/deploy.log记录了本周所有上线操作某天部署时写了一句git log /var/log/deploy.log之前的记录立刻清零。这不是命令报错Shell 不会给出任何提示数据丢失几乎是瞬间的。如果你希望阻止这种误操作可以在当前会话或脚本中开启 noclobber 选项set -C echo hello /tmp/test.log # 当 /tmp/test.log 已存在时会提示 # bash: /tmp/test.log: cannot overwrite existing file开启后不允许覆盖已有文件。如果确实需要强制覆盖使用|语法echo force overwrite | /tmp/test.log这个细节在日常命令中不常用但在写正式脚本时是很好的保护机制。4. 错误重定向2、2、21 与 /dev/null很多人在重定向上翻车不是因为不懂而是因为没搞懂标准错误。命令执行过程中的报错信息走的是 stderr也就是文件描述符 2它和标准输出是两条独立的通道。只重定向标准输出无法捕获报错。4.1 标准错误为什么要单独处理看一个常见例子find / -name *.conf /tmp/find_result.log由于权限原因find会产生大量 “Permission denied” 报错这些报错属于标准错误。上面这条命令只重定向了标准输出所以/tmp/find_result.log里只有正常搜索结果所有的权限报错仍然直接显示在终端屏幕上。如果因此以为 find 没有报错就会忽略真正的权限问题。正确的做法是把标准错误单独保存或者直接丢弃# 将标准错误单独写入文件 find / -name *.conf 2 /tmp/find_err.log # 将标准错误追加到已有日志 find / -name *.conf 2 /tmp/find_err.log4.2 合并标准输出与标准错误21更常见的需求是把正常输出和错误信息合并到同一个日志文件方便统一排查。最标准的写法是# 合并标准输出和标准错误到同一个文件 python3 deploy.py /tmp/deploy.log 21也可以使用 Bash 提供的简写形式# Bash 专用简写 python3 deploy.py /tmp/deploy.log # 追加模式 python3 deploy.py /tmp/deploy.log需要注意是 Bash 提供的扩展语法在 POSIX sh 中并不通用。为了脚本的可移植性正式脚本里更推荐使用 file 21这种标准写法。4.3 重定向顺序的关键陷阱这是重定向里最容易出错、也最值得强调的细节重定向符号按从左到右的顺序解析顺序不同结果可能完全不同。# 正确写法先把 stdout 指向文件再把 stderr 指向 stdout 当前的位置 python3 deploy.py /tmp/deploy.log 21 # 错误写法先把 stderr 指向 stdout 当前的位置此时还是终端再改 stdout python3 deploy.py 21 /tmp/deploy.log第二种写法中21先执行此刻文件描述符 1 还指向终端于是 stderr 也被指向终端随后才把 stdout 改为指向文件。最终结果是正常输出进入日志文件错误信息仍然留在终端。如果在脚本里用了这种写法看起来命令执行了、日志文件也生成了但真正的报错一条都没进日志排查问题时会被严重误导。牢记这个规则合并 stderr 到 stdout 时21必须放在或的后面。4.4 /dev/null 的合理使用/dev/null是 Linux 里的“黑洞设备”所有写入它的数据都会被直接丢弃。它适合用于丢弃那些“不需要关注”的输出。# 丢弃 find 的权限报错只保留正常结果 find / -name *.conf 2 /dev/null # 丢弃标准输出和标准错误 rm -rf /tmp/test_dir /dev/null 21这里要给一个提醒/dev/null很强大但不要滥用。在脚本中把所有错误都丢进黑洞会让故障排查变得极为困难。正确的做法是确认某类报错确实不需要关注时再丢弃例如 find 在扫描系统路径时必然产生的权限提示。对于业务脚本尽可能把错误写入日志文件而不是直接丢弃。5. 输入重定向 和 的高阶玩法输入重定向在日常命令中不如输出重定向常见但在脚本自动化、批量交互、配置文件生成这些场景中却非常有价值。输入重定向的本质是把命令的标准输入从键盘改成文件、字符串或一段文档。5.1 用 从文件读取输入# 将文件内容作为 sort 的标准输入 sort /tmp/names.txt # 统计文件行数注意这种写法不会输出文件名 wc -l /tmp/names.txt对比一下wc -l /tmp/names.txt和wc -l /tmp/names.txt的输出差异前者会显示文件名“/tmp/names.txt”后者只显示行数。原因是前者把文件作为参数传给命令后者把文件内容作为标准输入喂给命令。这个细微区别在脚本解析输出时偶尔会踩坑。5.2 用 Here Document 生成多行内容Here Document 是最常用的输入重定向形式它把一段多行文本作为标准输入传给命令常用于在脚本中生成配置文件、向交互式命令批量输入指令。# 创建多行配置文件 cat /tmp/application.conf EOF app.namedemo app.envproduction server.port8080 EOF这段命令把EOF之间的内容写入/tmp/application.conf。使用 Here Document 时有几个关键规则结束符必须单独占一行且顶格书写前后不能有空格或 Tab。结束符必须和起始标记完全一致区分大小写。如果不想让文档中的变量和命令被执行可以把起始标记加上引号EOF。namezhangsan # 不做变量替换 cat EOF 当前用户是 $name EOF # 做变量替换 cat EOF 当前用户是 $name EOF第一段输出字面量$name第二段输出变量实际值zhangsan。这个差异在生成配置脚本时经常用到。如果希望 Here Document 允许行首的 Tab 缩进并自动忽略它们可以使用-语法。这个技巧在脚本中缩进美观和内容正确之间取得了平衡。5.3 用 Here String 简化字符串输入Here String 是比 Here Document 更轻量的形式直接把一个字符串作为标准输入传给命令# 把字符串作为标准输入传给 bc 计算 bc scale2; 10/3 # 对字符串做 grep 匹配 grep error 2024-01-15 10:30:01 error: disk full它省去了解释器和文件的中间过程非常适合在脚本中快速测试命令行为。在 Bash 中可用POSIX sh 中不支持使用时同样要考虑脚本的可移植性。6. 管道 | 与重定向的配合管道符|是 Linux 命令组合的基石。它把多个命令串成一条流水线前一个命令的标准输出直接成为后一个命令的标准输入。很多复杂的运维操作本质上就是管道和重定向的组合运用。6.1 管道和重定向的本质区别重定向的连接对象是文件或设备管道的连接对象是另一个命令。把输出存到磁盘|把输出交给下一个程序处理。一个典型的组合是# 查看系统进程过滤出 nginx 相关进程 ps aux | grep nginx # 多级管道过滤、去自身、提取字段 ps aux | grep nginx | grep -v grep | awk {print $2, $11}这里每一级管道都在做一件事把上一个命令的输出转换成下一个命令的输入。使用grep -v grep是为了过滤掉 grep 进程本身这是 Linux 常用命令中最经典的细节之一。6.2 管道组合中的常见误区管道只连接标准输出不连接标准错误这一点在前文强调过。因此当你写find / -name *.conf | grep nginx时find 的权限报错不会进入 grep而是直接显示在终端。如果想让错误信息也进入管道参与过滤需要先合并find / -name *.conf 21 | grep nginx另外管道默认的退出码是最后一个命令的退出码。如果前面的命令失败但后面的命令成功整条管道的返回值可能仍然是 0。关于这个陷阱会在最佳实践部分给出解决方案。6.3 tee 命令既显示又保存tee命令解决了一个很实际的需求既想在屏幕上实时看到输出又想同时保存到文件。它的名字来源于管道“T 型三通”输出在这里分成两路。# 一边显示一边写入文件 echo 开始部署 | tee deploy.log # 追加模式不覆盖已有内容 echo 部署完成 | tee -a deploy.log更实用的场景是实时观察日志并保留副本tail -f /var/log/nginx/access.log | tee /tmp/access_backup.log这条命令会持续跟踪访问日志同时把流经它的每一行写入备份文件。注意tail -f是持续运行的命令需要按 CtrlC 终止。7. 命令替换、逻辑控制符号与通配符掌握了重定向和管道之后再补充几个脚本中高频出现、又容易被误用的特殊符号。它们不是重定向但经常与重定向同时出现在同一行命令里。7.1 命令替换 $() 与反引号命令替换的作用是把一条命令的执行结果嵌入到另一条命令中。最常见的场景是把时间戳拼进文件名。# 把 date 命令的结果作为变量值 backup_filebackup_$(date %Y%m