1. 文件描述符0/1/2先理解标准流的本质聊重定向之前我建议先把文件描述符这个概念理顺。很多人学Linux命令时总是把、、21当成记住就好的语法糖结果每次写脚本都要翻手册遇到21和换了个顺序就懵。这不是记性差是底层机制没建立起来。Linux里一切皆文件这句话你肯定听过。程序运行时操作系统会给每个进程维护一张文件描述符表这张表里的每一个数字都指向一个打开的文件或设备。标准输入、标准输出、标准错误这三个流对应的是这张表里靠前的三个固定槽位0stdin标准输入默认指向键盘。程序从这里读数据。1stdout标准输出默认指向终端屏幕。正常执行结果往这里写。2stderr标准错误默认也指向终端屏幕。错误信息往这里写。关键点在于0、1、2只是约定俗成的编号它们本身没有任何魔法。你可以显式地让程序从3号描述符读数据或者把错误写到9号描述符只要程序自己配合就行但绝大多数程序都遵循这个约定。理解了这一点你就能明白重定向的本质是什么。重定向的本质是修改文件描述符表里的指向。当你在Shell里输入ls output.txtShell做的事是先打开或创建output.txt这个文件得到一个文件描述符比如3然后把这个文件描述符复制到1号槽位替换掉原本指向屏幕的那个。之后ls进程启动时往1号描述符写的一切内容都会进到output.txt里。这个复制文件描述符的动作在Linux系统编程里叫dup2。Shell里的、21这些符号最终都是通过dup2系统调用实现的。所以别看21长得很奇怪它实际的语义就是把2号描述符复制成1号描述符当前指向的那个文件。注意是复制不是合并这两个词的区别后面会专门讲。2. 三个重定向符号的层级关系、、2.1 输出覆盖与追加和大家应该都熟但有个细节值得重新审视是截断写入也就是先清空文件内容再写入是追加写入在原有内容末尾继续写。这个区别在日志场景下特别重要但在脚本里很多人会忽略另一个隐藏行为——会先创建文件再执行命令。这句话怎么理解假设你写了一个脚本里面有一行echo start /var/log/app.log但/var/log目录权限不够Shell在重定向时就会直接报错echo这个命令根本不会执行。因为Shell的处理顺序是先完成所有重定向相关的文件打开操作再启动命令。这个特性在调试脚本时很有用如果你发现命令没执行、但文件被创建了说明问题出在重定向阶段而不是命令本身。2.2 输入重定向的常见误解是标准输入重定向用的场景相对少一些但有个使用频率很高的变体是Here Document和Here String。比如cat EOF hello world EOF这里的 EOF意思是把从下一行开始直到单独一行的EOF为止的所有内容作为标准输入传给cat。这个技巧在写自动化脚本、生成配置文件时非常常用。不过我想提醒一点后面的结束标记必须是独立的前面不能有空格否则Shell不认。则是把一个字符串直接作为标准输入比如grep error $log_line用代替echo $log_line | grep error少了一次管道进程的创建在循环里性能优势更明显。这是个小技巧但很多人不知道。2.3 关于符号的正确理解重定向里还有一个特殊写法比如这个不是后台运行的意思而是后面跟的是文件描述符而不是文件名。你可以理解为后面单纯跟一个数字时Shell会尝试打开名为这个数字的文件而后面跟数字时Shell会把它解析为文件描述符编号。举个例子ls 1 # 创建一个名为1的文件把ls的输出写进去 ls 1 # 把ls的输出写入到1号描述符标准输出指向的地方第一条命令在当前目录下可能多出一个叫1的文件第二条命令打印到屏幕。这个差异就是存在的意义。理解了这一点你就明白为什么21里的不能省也能理解为什么file 21和21 file行为不一样了。3. 输出拆分与合并file 21和21 file的坑这一节是全文的核心也是我认为每个Linux使用者都应该亲手验证一遍的实验。3.1 存储顺序决定重定向语义先看一个经典问题ls foo /dev/null 21和ls foo 21 /dev/null这两条命令哪条能让错误信息也进入/dev/null答案是第一条。原因就在于Shell按从左到右的顺序执行重定向。第一条命令的执行过程是先把1号描述符指向/dev/null21把2号描述符复制成1号描述符当前的内容也就是/dev/null第二条命令的执行过程是21先把2号描述符指向1号描述符当前的内容也就是屏幕再把1号描述符指向/dev/null结果第二条命令里错误信息仍然打印到屏幕只有标准输出被丢弃了。这个顺序问题几乎每个初学者都踩过。我见过不少生产环境的脚本排查半天发现就是写反了错误日志照常打印屏幕刷屏刷得人头疼。所以我的建议是写重定向时养成先指定文件、再复制描述符的习惯——file 21顺序固定不要反过来。3.2 用exec验证描述符状态有时候你需要确认当前Shell里某个文件描述符指向哪里可以用ls -l /proc/$$/fd查看。这个命令非常直观$ ls -l /proc/$$/fd lrwx------ 1 root root 64 Jul 1 10:00 0 - /dev/pts/0 lrwx------ 1 root root 64 Jul 1 10:00 1 - /dev/pts/0 lrwx------ 1 root root 64 Jul 1 10:00 2 - /dev/pts/0每一行就是一个文件描述符的软链接指向它当前对应的文件。你可以在这个状态下执行exec 1file再查看一次会发现1号描述符变成了指向file。这种验证方式比口头解释更有说服力我建议你自己在终端里跑一遍建立直觉。3.3 描述符合并与复制的深层区别前面提到21的语义是复制不是合并。这有什么区别如果你在31和21之后又改变了1的指向那2和3会跟着变吗要回答这个问题得回到dup2的行为上。dup2(2, 1)的含义是让2号描述符和1号描述符指向同一个文件表项。这个同一个文件表项很关键——它们共享同一个文件偏移读写位置。比如exec 31 # 3号复制1号指向屏幕 exec 1log.txt # 1号重新指向log.txt echo hello # 输出进log.txt此时3号描述符仍然指向屏幕因为31是在1被改变之前完成的复制。Shell里的重定向都是一次性的每次符号解析完复制关系就固定了不会持续联动。所以如果需要先备份1号描述符之后恢复正确做法是exec 31 # 备份3号保留当前屏幕 exec 1log.txt # 1号指向日志文件 echo 写入日志 exec 13 # 恢复1号重新指向屏幕 exec 3- # 关闭3号描述符最后的3-是关闭3号描述符这行容易被漏掉但每次脚本退出前不手动关闭也没有大碍进程结束后所有描述符自然释放。4. 实战案例管道、子Shell与描述符生命周期4.1 管道只连接标准输出管道的设计初衷是连接标准输出和标准输入它不处理标准错误。所以你看到cmd1 | cmd2时cmd1的stderr仍然会直接打到终端只有stdout进入管道。这是一个经常让人困惑的点。一个常见的需求是想同时把stdout和stderr都丢进管道比如cmd 21 | tee log.txt。这里的顺序依然重要21必须出现在管道符号之前因为Shell解析命令时管道在重定向之前建立。正确的写法是cmd 21 | tee log.txt如果你写成cmd | tee log.txt 21那21只会影响tee这个命令cmd的错误照样漏到屏幕。这又是一个顺序问题但很多人在管道场景下会忽略。4.2 管道的子Shell与描述符状态管道还有一个隐藏属性管道两侧的命令各自运行在独立的子Shell里。这意味着你在管道左边设置的重定向或变量不会影响右侧。试看# 错误示范 echo abc | read line echo $line # 输出为空因为read运行在子Shell里同样的道理如果你在管道里边执行exec 2error.log这个重定向只对管道左侧的子进程有影响不会改变你当前Shell的2号描述符。了解了子Shell的边界你的脚本才不会出现明明重定向了但控制台还在刷错误这种诡异现象。4.3 日志场景中的实际用法写应急响应脚本或定时任务时经常要处理标准输出和错误信息分别入文件的情况。一个典型的模式./deploy.sh deploy.log 21这样stdout和stderr全部追加到同一个日志文件。但有的时候你需要拆开业务日志放一个文件错误告警放另一个文件。./deploy.sh deploy.log 2 error.log注意两个是独立打开文件的各自有自己的偏移所以顺序未必能保证严格交错。如果你想记录严格按时间混排的完整执行过程还是要合并到同一个文件里。这里我还想提一个容易被忽略的细节如果两个描述符指向同一个文件但它们不是通过21复制得到的而是通过两次独立的打开比如上面的两条那么它们的文件偏移是各自独立的。这可能导致写入互相覆盖。如果文件不太大、写入次数不多通常看不出来但高并发写入时这是个隐藏炸弹。解决办法就是使用描述符复制确保它们共享同一个文件偏移。4.4 日志轮转与文件描述符还有一个生产中一定会遇到的问题用重定向写日志然后你用logrotate切了日志文件发现程序继续往旧文件已被改名里写新文件一直不涨。原因在于重定向是在程序启动时打开文件并绑定描述符的logrotate改名的只是目录项程序持有的文件描述符仍然指向旧的inode。要用logrotate的copytruncate选项解决或者在程序里支持重新打开日志文件比如发送信号触发。这个和重定向本身相关但不完全是Shell层面的问题但弄懂了文件描述符与文件名的关系后你就更容易理解为什么会有这种现象了。5. 排错思路输出去向不明时的排查链路5.1 标准问题为什么权限错误还在屏幕很多人在排查DNS配置或服务启动失败时会先看/var/log下的日志文件结果发现里面空空如也但屏幕上明明有错误。我见过不少新人卡在这种问题上其实是没搞清楚屏幕上的报错很有可能是进程的标准错误它根本没被重定向到日志文件里。比如systemd管理的服务如果你在Service配置里不写StandardError默认会继承到journald。而手动用nohup ./app app.log 启动时只有stdout进入了app.logstderr可能仍然输出到nohup.out或者直接显示在终端。所以排查时要先明确这条命令的重定向覆盖了哪个描述符错误信息走了哪个描述符5.2 排查步骤逐步检查输出流向结合我自己的经验当你发现某个命令的输出不见了或者某条错误没有落进预期文件 按这个顺序排查确认命令本身的退出码echo $?。退出码为0不代表没有stderr输出只是程序认为执行成功。检查当前Shell的描述符指向ls -l /proc/$$/fd看1号和2号分别指向哪里。把重定向拆开测试先只做file看stdout是否进文件再单独做2file确认stderr是不是单独进入了。用strace -f -e tracedup2,open,openat -o /tmp/strace.log cmd跟踪Shell在执行这条命令时到底调用了哪些open和dup2。这个办法能直接看出重定向的完整过程强烈推荐。第4步可能会让新手觉得有点重但实际排查复杂问题时特别管用。strace输出的关键行长这样openat(AT_FDCWD, file, O_WRONLY|O_CREAT|O_TRUNC, 0666) 3 dup2(3, 1) 1 close(3) 0这三行清晰展示了file的完整实现打开文件获得3号描述符把3号复制到1号然后关闭原来的3号。看懂了这三行你对Shell重定向的理解就超越了绝大多数人。5.3 常见错误21的位置写错再举一个真实例子。有人写定时任务30 2 * * * /opt/backup.sh /dev/null 21这个脚本执行时一旦报错错误信息全被丢掉了。改法是要先记录错误再丢弃或者保留一份排错日志30 2 * * * /opt/backup.sh /var/log/backup.log 21这里没什么高深技巧但顺序一旦搞反结果完全不同。我建议在脚本头部统一加上exec $LOG_FILE 21这样整个脚本后续所有命令的stdout和stderr都会自动进入同一个日志文件再也不用每个命令都加一次重定向。5.4 用exec把重定向变成全局配置exec结合重定向的用法很多人不敢用觉得复杂。其实原理刚才已经讲过了exec不加命令名时只修改当前Shell的描述符状态。例如#!/bin/bash exec 1/var/log/app.log 21 echo 脚本开始执行 some_command从exec这行起后续所有命令的输出和错误都会进入app.log屏幕上看不到任何信息。如果你想在脚本里同时保留一份屏幕输出可以在前面套一层teeexec 1 (tee -a /var/log/app.log)这个(...)叫进程替换属于高级用法展开讲又是一篇长文。不过这里先记住一个关键点进程替换创建的是一个临时文件描述符配合tee可以实现既写文件又写屏幕的效果比用管道子Shell更灵活。6. 一类容易混淆的高级场景进程替换与描述符复制6.1 命名管道与临时文件描述符也许你已经注意到(...)也是重定向相关的一个能力。它的本质是创建一个管道Shell把管道的写入端绑定到某个文件描述符上然后把这个描述符作为文件路径传给命令。最常见的场景diff (ls dir1) (ls dir2)这里的(...)是进程替换的输入形式Shell会为括号里的命令创建管道并把管道的读端当作一个文件路径传给外层命令。所以diff这个进程接收到的是两个文件名打开它们时实际上是从管道里读数据。这类用法的好处是避免创建临时文件坏处是它创建了管道带来管道的所有特性数据流有大小限制默认64KB缓冲如果生产方产出数据过多消费方读得慢生产方会被阻塞。所以在处理超大批量输出时进程替换并不总是优于临时文件方案。6.2 描述符复制与关闭的实用场景除了21这种标准用法描述符复制还能做很多非常规操作。比如有时候你想让tee的输出进文件同时保留一份加密管道exec 31 echo data | tee /dev/stderr 3这条命令把echo的内容同时输出到标准错误和3号描述符即标准输出。调试时很有用可以确保tee分支的输出能同时看到。理解了3的本质是复制3号描述符你就能自由组合出各种需要的流向。6.3 交互式Shell与脚本的差异交互式Shell的默认配置和脚本环境不同比如交互式Shell可能开了job control脚本里设置set -o pipefail、set -e等也会改变行为。这些都和重定向有关系——例如set -e在管道失败时的退出行为往往牵涉到管道两侧的退出码处理。我建议在脚本开头加上set -euo pipefail其中pipefail让管道中任一命令失败整个管道的退出码即为失败避免出现明明中间命令出错了但管道最后一条命令成功脚本继续执行的问题。这和重定向配合后日志里的错误退出时机更准确排查时才不会漏掉中间环节。7. 踩坑实录重定向引发的三个真实故障7.1 清空日志文件的风险操作场景磁盘满了有人手动执行echo /var/log/nginx/error.log想清空日志结果发现Nginx的写入不生效了。原因和4.4节说的一样——Nginx持有的描述符指向旧inode你用截断并重建文件只是换了目录项Nginx仍然写旧文件磁盘空间根本没释放。正确做法是truncate -s 0 /var/log/nginx/error.log它在不改变inode的前提下把文件长度清零。这个操作对描述符绑定完全无影响。重定向操作看似简单但直接作用于生产文件之前最好先确认目标文件是否被其他进程用描述符绑定着。7.2 nohup与stderr的“消失”场景用nohup ./a.sh 启动脚本脚本里的错误信息不见了一部分。原因是没有显式重定向时nohup默认将stdout写入nohup.out但stderr并没有自动进入该文件仍然继承当前终端。当你关闭终端时stderr写入方失去终端可能直接丢弃。于是看起来就是日志文件不完整错误缺失。解决方法很简单nohup ./a.sh nohup.out 21 。注意21必须跟在nohup.out后面顺序不能乱。7.3 与sudo搭配时的重定向失效还有个非常经典的坑sudo echo hello /etc/hosts会报Permission denied。表面上是重定向不受sudo管辖——实际上sudo只让echo以root权限运行但Shell的重定向发生在启动echo之前用的是当前用户的权限打开文件。所以文件打开失败命令还没执行就退出了。正确写法是sudo bash -c echo hello /etc/hosts或者echo hello | sudo tee /etc/hosts /dev/null这种坑在写自动化脚本时特别容易踩到而且报错信息还不明显。我现在写脚本时凡是需要root权限的重定向都习惯性检查一遍是不是把重定向放进了sudo的作用域里。7.4 重定向造成死循环最后说一个比较冷门的场景。在某次无限循环读取配置时脚本里有行while read line; do ...; done file如果循环体里有命令把输出覆盖到同一个file里就可能出现一边读一边改同一份文件的情况具体表现诡异难以排查。这个问题的根因在于输入和输出共享了同一个文件描述符实际上 file是只读打开是截断打开两个不同的文件偏移。但如果你用追加写入时文件大小变化read的读取位置可能重复。这种自身写自身的重定向操作极容易造成无限循环或数据错乱建议务必使用临时文件。8. 进阶测试用实验巩固概念8.1 一组可以亲手做的对比实验建议在终端里依次执行下面的命令并把每一步的输出和文件内容记录下来# 实验1验证顺序影响 ls /no/such/file /tmp/out.txt 21 cat /tmp/out.txt ls /no/such/file 21 /tmp/out.txt cat /tmp/out.txt对比两次cat的结果第二次会明显发现错误信息仍然在屏幕上。# 实验2验证描述符指向 exec 31 exec 1/tmp/redirect_test.log echo this should go to log exec 13 echo this should go to screen执行完查看/tmp/redirect_test.log内容只有第一条echo进去了。# 实验3管道只传stdout set -o pipefail ls /no/such/file | grep no such执行后会看到ls的错误信息直接打到终端而grep在管道里什么都没收到因为stderr没有进入管道。这些实验做完你对重定向的理解会比读十篇文章都深刻。我自己当年就是靠一遍遍敲这些命令才真正记住语法顺序的。8.2 Bash与sh的差异还要提醒一点很多脚本在bash下正常但切到shdash下就跑不通。比如 word这种写法在dash下的解析可能不同进程替换(...)在dash中也不支持。如果你的脚本要兼容多个发行版建议用bash作为解释器或者重点测试sh下的行为。8.3 招聘和面试中常见的考察方式从最近的热搜词来看linux面试题测试、linux常用命令大全这类话题热度很高。重定向恰恰是面试官最爱问的点之一而且经常出陷阱题。最常见的就是本文反复强调的顺序问题、以及/dev/null和/dev/zero的区别。回答这类问题的时候如果能从文件描述符底层机制讲起而不是只背结论面试官通常会高看一眼。9. 最后的经验总结我在实际使用中有一个体会重定向的报错不要只看表面。比如No such file or directory有时是文件真的不存在有时是路径权限不够导致无法打开有时则是重定向目标文件本身依赖的目录不存在。区分这些情况最直接的办法就是查看Shell是怎么逐条解析重定向的strace加描述符列表能帮上大忙。还有一个小技巧收尾写任何带重定向的脚本时先在交互式Shell里用echo test file验证文件名和权限再用ls -l /proc/$$/fd/1确认描述符指向最后再跑真正的命令。这个习惯养成了能省掉大量排查时间。重定向这东西刚学时觉得简单用久了才发现细节很多。希望这篇梳理能帮你把0、1、2这三个数字彻底刻在脑子里。之后不管看到多复杂的Shell命令只要沿着文件描述符这张表的改动顺序推一遍就不会再被绕晕了。