从接触shell的第一天开始重定向就是绕不开的基础操作。但很多人在写脚本时对、、21、/dev/null这些符号的理解往往停留在背下来能用的层面一旦遇到顺序问题、描述符复用、进程替换这些场景就容易被绕晕。这篇文章会从文件描述符的本质讲起把输入输出重定向、管道协同、高级描述符操作全部串一遍再附上我这些年实际踩过的坑和排查思路。不管你是刚学Linux命令行的新手还是已经写了一阵子脚本但总觉得哪里差点意思的人这篇内容应该都能帮你把重定向这块补扎实。1. 重定向的本质先搞清楚程序的数据流从哪来、到哪去1.1 标准输入、标准输出、标准错误分别是什么Linux里每个进程天生带着三个数据通道标准输入、标准输出、标准错误。简洁地说标准输入是程序读取数据的地方默认是键盘标准输出是程序打印正常结果的地方默认是终端屏幕标准错误是程序输出错误信息的地方默认也是屏幕。这三者分别对应文件描述符0、1、2。文件描述符可以理解成操作系统给每个打开文件发的一个数字编号程序想读写某个文件就通过这个编号去找。0号代表标准输入1号代表标准输出2号代表标准错误。重定向操作的本质就是把某个编号的数据通道从默认的目标改接到另一个文件或设备上。举个最直观的例子执行ls /nonexistent时命令找不到目录错误信息会打印到标准错误也就是2号通道。这时如果你只想保存正常输出就可以只重定向1号通道。我见过不少新手写ls /nonexistent out.txt 2 err.txt然后疑惑为什么屏幕上还是能看到报错——那是因为没搞清楚错误走的是2号通道单独重定向1号当然拦不住它。很多教科书喜欢用三个水龙头来类比重定向但我个人觉得用三根管道更贴切程序内部有三根默认接通到固定地点的管道重定向就相当于把其中某根管道换接到你指定的新地方。默认地点是终端新地点可以是文件、设备、另一个程序的输入口甚至是黑洞。1.2 为什么说重定向而不是输出到文件这里值得展开一点。符号并不是让输出保存到文件它的准确含义是把文件描述符1所指向的目标文件替换为另一个文件。shell在执行一条带重定向的命令时会先打开重定向指定的文件把它设置为文件描述符1的目标然后再启动命令进程。因此如果命令本身没有输出那个文件也会被创建或截断这就是为什么 file单独执行时能创建一个空文件或把已有文件清空。反过来如果重定向的目标文件打开失败比如没有权限shell会在启动命令前就报错命令本身根本不会执行。明白了这个机制就能解释很多怪现象。比如echo hello /root/test.txt如果不是root用户会直接提示权限不足而echo hello本身是不会失败的。因为重定向是 shell 先做的动作命令根本没轮到执行。这个原理在调试脚本时特别有用——当你发现某个命令没跑第一反应应该是去看重定向打开文件是否成功而不是怀疑命令写错了。还有一个常见的认知误区有人以为重定向只影响命令的输出。实际上输入重定向同理就是提前把某个文件打开绑定到0号描述符上让进程从文件里读数据而不是从键盘读。理解了打开文件并绑定描述符这个动作发生在命令启动之前你对重定向的各种奇奇怪怪的行为就能豁然开朗。2. 输出重定向的几种姿势与高频坑点2.1与覆盖还是追加选错就丢数据这两个符号是重定向里最基础也最容易造成事故的。会创建新文件如果文件已存在会直接清空内容再写入叫做覆盖。则是把内容追加到文件末尾不会动原有内容。我有一回写自动备份脚本早上起来发现备份文件大小是0查了半天才发现脚本里写的是而不是加上循环结构又把同样的文件覆盖了无数次最后只留下了最后一次循环的输出。从那之后我在所有需要累积记录的场景里一律只用凡是看到都要多问一句如果这个文件已存在丢掉里面的旧内容真的没问题吗覆盖模式并不是一无是处比如生成临时文件、写锁文件、清理旧日志的场景反而正好。关键是要形成条件反射收集型用覆盖型用。还有一种写法是|强制覆盖这是为了避免 shell 开启了set -Cnoclobber保护后覆盖失败而设计的。如果脚本里有set -C普通遇到已存在文件会报错|则可以绕过这个限制强制覆盖适合那种我就是要覆盖的场景。日常写脚本时建议对可能已经存在的文件统一采用然后配合: file这种用法来主动清空。是shell内置命令什么都不做但: file因为重定向发生在命令执行前所以能先创建或清空文件比 file可读性好那么一点也能明确表达我要清空它的意图。2.2 合并标准输出与标准错误21与的写法辨析最经典的写法是command file 21表示把标准输出重定向到文件再把标准错误也指向标准输出当前的位置——也就是同一个文件。这里有一个极其关键的顺序问题21必须放在 file之后。如果反过来写command 21 file事情就拧了。执行顺序是先把标准错误合并到标准输出当前的位置此时标准输出还是终端所以错误信息还是会打到屏幕上然后把标准输出改接到文件。最终效果是错误出现在屏幕正常输出进入文件。这跟预期完全相反但很多人踩进去出不来。为什么顺序这么重要因为21中的1是复制文件描述符而不是永远绑定。它做的是把2号描述符指向1号描述符当时所指向的目标文件注意是当时。一旦后续1号描述符被重新定向到别的文件2号仍然停留在原来的目标上。想同时把1和2都送进同一个文件顺序必须是 file 21。另一种写法是比如command file它的语义就是标准输出和标准错误都进这个文件。这个写法在Bash里支持良好而且顺序无关简洁很多。现在写新脚本我用得更多。不过要注意在POSIX sh比如 dash里不一定支持如果你的脚本需要跑在各种环境里还是用 file 21更稳妥。2.3/dev/null数据黑洞的正确打开方式/dev/null是一个非常特殊的设备文件写入它的数据会被系统直接丢弃读取它则永远返回文件结束标志。它有两个核心用途丢弃不需要的输出以及提供空输入。丢弃输出最常见的场景是command /dev/null 21用于屏蔽正常输出和错误。比如后台任务里你只关心任务是否执行成功不想被一堆日志刷屏。还有些命令本身会打印一些无关紧要的 banner 信息也可以直接丢进黑洞。但不要盲目把所有输出都丢进/dev/null。调试脚本时错误信息往往是定位问题的唯一线索屏蔽之前想想是否真的不需要。我一般建议在开发阶段保留错误输出接近正式运行时才做静默处理。另外如果命令的退出码本身不反映问题你把输出丢了也没意义这时候更应该关注的是退出码配合管道来设计而不是一味屏蔽。/dev/null还能用来快速清空大文件比如 /var/log/big.log或cat /dev/null /var/log/big.log这比rm再重建一个文件更安全、更好——它不改变文件权限和属主只是把内容清零对正在写这个文件的进程也不会有影响。3. 输入重定向让程序从文件而不是键盘读取数据3.1 基础输入重定向f时 file让程序从文件读很多脚本新手对输入重定向比较陌生因为日常写脚本时输出重定向用得多输入重定向看起来好像是多余的。实际上输入重定向能让我们把交互式程序变成批处理模式这是自动化的重要一环。比如cat file和cat file表面上都能把文件内容打印出来但原理不同。cat file是让 cat 程序自己打开文件cat file是 shell 先打开文件再把它当作标准输入喂给 catcat 的重点就只是读标准输入。这区别在有些场景会暴露出来——比如文件路径带特殊字符时cat file可能因为 shell 解析而出现问题而直接传参数更直接。但反过来需要把程序当作标准输入过滤器来用时就必不可少。最实用的场景是给一些默认从标准输入读取数据的命令喂数据。像sort unsorted.txt或者grep pattern file.txt虽然这些命令自己也能接受文件名参数但一些第三方工具或者你自己写的脚本可能只接受标准输入。还有像wc -l file这种用输入重定向可以避免输出中额外出现文件名这在脚本里做数字运算时能少做一次字符串处理。3.2 Here Document在脚本里内嵌多行输入Here Document是我个人认为shell中最被低估的特性之一。它允许你在脚本内部直接嵌入一大段文本作为命令的标准输入不需要额外创建临时文件。基本写法是cat EOF 第一行 第二行 EOF当shell遇到EOF时会从下一行开始读取直到遇到一个独立成行且内容正好是EOF的行把中间的所有内容拼接成标准输入送给左边的命令。这里EOF只是一个约定俗成的标记你可以用任何字符串比如END、DATA关键是结束标记必须与起始标记一致且单独占一行。Here Document最有价值的地方在于配合交互式命令做自动应答。比如连接数据库执行一段SQL脚本或者用ssh到远程机器执行一串命令交互式场景下你没法手动输入用 Here Document 就能一次性把完整的输入流喂进去。一个关键技巧-EOF允许行首出现tab键shell会自动忽略这些tab。这样写在缩进的脚本块里代码看起来不会乱。但要注意只有tab会被忽略空格不行。如果你写的是四个空格缩进结束标记前面有空格也会导致匹配失败。这是很多新手容易踩的坑明明看着居中就是报没结束。再就是变量展开问题。默认情况下Here Document 里可以进行变量替换和命令替换。也就是说$HOME、$(date)会被展开成具体内容。如果你希望原文输出、不做任何替换就要把标记用引号包起来EOF或\EOF\。这在写脚本模板、生成配置文件的场景里非常常用——有时候你就想要字面意义的$变量名而不想让shell把它替换掉。3.3 Here String把字符串直接当作标准输入Here String 用表示语法是command 字符串。它本质上等于一个极其简化的Here Document把一整个字符串可以包含空格、换行作为标准输入送给命令。典型用法是配合read命令比如read a b hello world这样变量a得到hellob得到world。没有Here String的时候通常要echo hello world | read a b但因为管道会使 read 在子shell中执行读完变量就丢了反而麻烦。Here String 因为是shell内置机制避免了这个问题。还有md5sum abc这类用法用于给字符串直接计算哈希。注意Bash的Here String默认会在字符串末尾补一个换行符所以md5sum abc算的是 abc\n 而不是 abc。如果严格需要不换行还是要用printf %s abc | md5sum。这个细节在我调试校验和时坑过我好几次写下来提醒一下。4. 重定向与管道数据流转的两种思路4.1 管道与重定向的区别和协作管道用|连接两个命令作用是把左边命令的标准输出接到右边命令的标准输入。从数据流的角度看管道的效果有点像把 临时文件和 临时文件串起来但管道走的不是磁盘而是内存中的缓冲区速度更快而且不会产生临时文件垃圾。管道和重定向的核心区别在于重定向涉及的是文件管道涉及的是另一个进程。echo hi file是把输出送到文件echo hi | grep hi是把输出送给 grep 进程继续处理。你完全可以在一条命令里混用管道和重定向比如command1 | command2 out.txt 21这时候command1的输出进入管道command2的输出被重定向到文件。有个经典问题管道左侧命令的标准错误默认不会进入管道右侧。如果你想把错误也一起交给右侧处理仍然要显式合并比如command1 21 | command2。这时候容易重复踩重定向顺序的坑21必须出现在管道符号之前而且它把标准错误指向的是标准输出的当前位置——也就是管道入口。这个我在自己项目里写过无数次每次都得停下来想一遍顺序。4.2 tee一边存文件一边看输出tee命令的名字来自T型接头作用是把标准输入同时送往标准输出和一个或多个文件。它解决的核心痛点是当你希望保留输出到文件又不想错过屏幕上的实时显示时用管道接tee而不是直接重定向。基本用法是command | tee output.txtcommand 的标准输出会被 tee 原样打印到屏幕同时写入文件。想要追加就用tee -a想要把标准错误也截获先21合并再交给 tee。tee 还有一个进阶用途在管道中间插入调试节点。比如command1 | tee step1.log | command2这样你能在推进数据到下一阶段前先检查command1产生了什么。我的习惯是在复杂的数据处理流水线里每隔一两步放一个 tee 到调试日志等确认逻辑无误后再移除。这比一次性失败后回头找原因要省力得多。需要留意的是 tee 默认会覆盖文件连续执行多次流水线时第二次跑会清空第一次的记录。如果想把多次运行的结果累积下来记得用tee -a。4.3 进程替换让管道支持多输入单输出进程替换是Bash提供的高级功能写法是(命令)和(命令)。它把命令的输出包装成一个虚拟文件或者把某个位置包装成虚拟文件来接收输入从而绕开管道只能一对一的限制。最常见的场景是比较两个命令的输出diff (sort file1) (sort file2)。如果不这样做你得先分别把排序结果存到临时文件再 diff 这两个临时文件最后还要清理。进程替换就不需要这一步。进程替换的原理是shell 创建了一个命名管道FIFO或 /dev/fd 机制让进程的输出可以像一个文件路径那样被引用。你用echo (true)会看到一个类似/dev/fd/63的路径这就是虚拟文件的文件名。不过进程替换在某些 shell 环境下不支持比如 dash。如果脚本要在纯净的 POSIX 环境运行我一般避免使用或者退回到临时文件方案。进程替换还有一个微小但烦人的限制(命令)中命令的输出是异步生成的如果命令特别慢可能你还没读到数据就超时了。这时回头用临时文件反而更可控。5. 文件描述符的高级操作exec重定向与自定义描述符5.1 exec重定向让整个脚本的数据流改道exec内置命令可以让重定向不再局限于某一条命令而是直接影响当前shell进程本身。最常见的用法是exec logfile 21执行之后脚本里后续所有命令的输出都默认写到 logfile标准错误也一样直到脚本结束或显式改回。这比每个命令后面都挂一个重定向优雅太多。我写过不少定时任务脚本开头统一加一行exec $LOGFILE 21然后脚本里的 echo、命令输出全都会自动落进日志文件。还要注意如果脚本里既有输出又有错误但你想保留交互式输入可以只重定向输出不重定向输入。使用exec重定向前要想清楚一件事它是永久改变当前环境之后的调试信息你也看不见了。所以开发调试阶段我一般不会在脚本开头放 exec 重定向等脚本稳定了再放。调试时真想模拟的话建议开两个窗口其中一个跑脚本看日志文件另一个tail -f实时观察。exec还有一个常见玩法是改变标准输入exec input.txt之后脚本内所有需要读标准输入的命令都会从该文件读取。这在批量处理固定输入源时有用但要注意一旦文件读完就是EOF后续命令再读会得到空值。别在同一个脚本里既读取又反复消耗同一条输入流容易莫名奇效。5.2 手动打开自定义文件描述符Bash允许通过exec N file或exec N file来创建自定义文件描述符编号可以从3开始0、1、2已被占用。为什么要自定义描述符因为某些场景下你希望一个进程能保留多条独立的文件写入通道而不是所有输出混在标准输出里。一个典型需求脚本需要同时写两份日志一份给调试日志一份给重要结果。你可以这样干exec 3 debug.log exec 4 result.log echo debug: start 3 echo RESULT: 42 4 exec 3- exec 4-3表示把标准输出重定向到描述符3对应的文件。这样调试信息进debug.log结果进result.log互不干扰。这比分别重定向每条命令的参数要清晰得多。自定义描述符用完以后要关闭用exec 3-表示关闭编号3。忘记关闭虽然通常不会立刻出问题但在长期运行的脚本里文件描述符数量会累积最终可能触发too many open files错误。这属于资源泄漏写保守一点没坏处。还有一个比较实用的场景是配合输入exec 5 data.txt之后read -u 5 line可以从描述符5指定的文件逐行读取。这样与标准输入完全隔离即使脚本的其他部分还在用标准输入读用户交互也不冲突。5.3 重定向顺序决定生死一次综合复盘本章关键就是把顺序逻辑彻底理顺。前面讲21 file和 file 21的区别更一般化的原则是重定向是从左到右依次执行的每个重定向只影响当前描述符的指向而N是把描述符复制到N当时指向的目标。所以command file 21的执行过程是先把1号指向 file再把2号复制为1号当前指向即 file。结果1和2都进文件。command 21 file的执行过程是先把2号复制为1号当前指向即终端再把1号指向 file。结果2号停留在终端1号进文件——错误还是没有进文件。为了彻底避免这种混乱我有两个构建安全重定向组合的检查步骤。第一先写目标文件重定向 file或 file第二再写21。顺序永远是先1后2、先文件后复制。如果你发现自己写了一条命令里同时有管道和重定向也按这个逻辑推演一遍管道建立后1号就是管道入口此时21该放在管道符号之前还是之后要先想再写。用图表描述的话重定向的顺序相当于一条装配流水线每一步改接一根管子的出口。你改了1号2号不会跟着变你改了2号1号也不会变。只有显式的系列操作才会产生复制当前指向的效果。只要记住这一点所有顺序问题都不再是难题。6. 常见问题与排查技巧实录6.1 我碰过的几个高频故障案例第一个典型问题是覆盖导致历史数据丢失。某次我写脚本统计用户在线时长日志文件用保存中间结果结果循环里每次迭代都把文件清了最后只有最后一条数据。排查时看脚本才发现覆盖模式用错了位置。这个教训直接改变了我写脚本的方式凡是追加一律我还会在删除或覆盖关键文件前先cp一个备份成本极低但能救命。第二个坑是管道导致变量丢失。写了echo hello | read var之后同一层级的脚本后面再输出$var发现是空的。原因是管道右侧的命令运行在子shell中子shell里的变量不会影响父shell。解决办法可以用后面要讲的进程替换或Here String也可以干脆把 read 安排在管道外部。很多新手在这里困惑很久实际上就是进程隔离造成的。第三个坑是我帮别人调试过的脚本明明把错误重定向到了文件屏幕上还是有报错。查了半天发现脚本里有一段用了管道管道左侧命令的错误没合并到标准输出就接了下一个命令而整个脚本只重定向了标准输出。错误整个从管道左边漏了出去打印到屏幕上。处理方式是给管道左侧加21或者把所有命令包进{ ...; }再统一重定向。6.2 如何有条理地排查重定向问题如果脚本输出不符合预期我推荐按下面几步来排查。第一步看命令的退出码echo $?如果非0先解决报错原因别缠着重定向。第二步跑一个简化版本去掉重定向直接看原始输出长什么样明确正常输出和错误信息分别出现在哪里再对照重定向配置。第三步合理使用bash -x追踪执行过程它会把每条命令的参数展开后打出来重定向发生的位置也看得出来。还有一种更硬核的排查法用strace跟踪命令的系统调用它能显示shell打开哪些文件、哪些描述符被复制重定向的每一步都清清楚楚。不过 strace 输出量大我一般只在问题特别诡异时才用。平时写复杂重定向组合时我喜欢先在一个临时目录里做实验用一个简单的echo或ls验证逻辑再套到真实命令上。这样能快速排除语法对不对这个变量确认是逻辑问题还是环境问题。6.3 实用经验补充别让重定向毁掉脚本可维护性最后说几个维护性层面的事情。重定向符号在长命令里非常多稍不留神就会看错。我的建议是对于明显的、单行的重定向直接写在命令尾部而对于复杂的、多文件的场景优先用exec或自定义描述符集中管理而不是每条命令都堆一大串21到文件那样可读性很差。还有一个习惯很值得养成在脚本里给所有重定向目标文件都加上变量而不是硬编码路径。比如LOG_FILE/var/log/myapp/run.log然后exec \$LOG_FILE\ 21。这样既方便修改也减少了路径拼错的可能性。另外如果你在写服务端脚本或者定时任务一定记得重定向到/dev/null不等于万事大吉日志还是要保留的。空输出很难排查问题我见过太多线上脚本因为/dev/null 21把错误全吞了结果故障发生时什么都查不到。正确的做法是把无关紧要的输出丢到/dev/null错误或关键状态反而要写到日志或者至少保留退出码并打一份精简记录。在我自己日常操作中最重视的还是顺序和时机这两个点。重定向不是死记硬背的咒语而是一套有逻辑的数据流控制机制。你把它想成水管工重新布置管道先拆哪根、再接哪根、最后试水压每一步都有因果。一旦你用这种眼光看待重定向那些曾经让你挠头的命令组合基本都能一眼看懂。最后再送一个我常年用的小技巧测试任何重定向组合时先跑echo test然后故意跑一个ls /no/such/file来制造错误输出。这样一分钟之内你就能验证当前顺序到底是把正常输出和错误都合并了还是各自分开了。用最小的代价换最确切的答案这种验证习惯在shell里永远不过时。