1. 重定向这件事你真正搞懂了吗先问个场景你在终端里跑了一条命令屏幕上哗啦啦滚了一堆输出里面既有正常日志也夹着几行红色的报错信息。于是你想把内容保存到文件里方便排查顺手敲了command log.txt 21。然后呢可能一切正常也可能某个瞬间你突然被问住和到底差在哪21为什么要写在后面21和 file又有什么区别如果你能脱口而出那这篇文章权当温习如果有点含糊那这篇就是为你准备的。标准输出stdout和标准错误stderr重定向是 Linux 命令行最基础也最容易被忽视的能力之一。很多同学用了一年多 /dev/null 21但从来没想过这条命令为什么长这样、背后是什么机制在支撑。我最近带了不少刚转行做运维和嵌入式的同事发现这个点几乎是所有人的共同盲区。所以今天专门用一篇文把文件描述符、重定向符号、常见组合、脚本实战、踩坑日志一次性讲透争取你看完就能直接拿去用。这篇文章适合这些人刚入门 Linux 想系统补基础的新手、写 Shell 脚本总是被日志输出搞懵的开发者、做运维或嵌入式开发需要处理大量命令输出的工程师。读完之后你不仅能看懂网上一堆“命令大全”里各种、2、的写法还能自己推导出没见过的写法是什么意思从此在命令行输出处理上不再心慌。2. 核心思路拆解一切重定向都是“文件描述符的游戏”2.1 先理解 Linux 里的“一切皆文件”Linux 世界里有一条铁律一切皆文件。普通文件是文件目录是文件设备是文件甚至网络连接、管道、进程之间的通信通道在操作系统层面都可以用文件描述符file descriptor简称 fd来代表。文件描述符本质上是一个非负整数是内核为了管理进程打开的文件而分配的索引号。进程通过这个数字就能找到对应的内核数据结构然后读写数据。一个进程启动的时候默认会打开三个文件描述符0标准输入stdin默认连接终端键盘1标准输出stdout默认连接终端屏幕2标准错误stderr默认连接终端屏幕注意标准输出和标准错误默认都指向屏幕所以你在终端里既有正常的命令结果也能看到报错信息。但它们的语义是不同的标准输出是程序正常的运行结果标准错误是程序运行中产生的诊断信息、警告、错误。设计上把它们分开就是为了让你在重定向时能灵活取舍——日志归日志错误归错误各走各的通道。这里有个新手经常懵的点既然 0、1、2 是默认分配的文件描述符那是不是说任何新打开的文件描述符都是从 3 开始排对完全正确。你在 Shell 脚本里打开一个新文件通常拿到的 fd 就是 3。这为后面的高级玩法埋下了伏笔比如你可以把某个文件的 fd 复制到另一个位置甚至把整个进程的输出通道重定向到任意文件。理解了 fd 是整数、是索引再看各种重定向符号就完全不神秘了。2.2 重定向的本质把“默认通道”换成别的“目标”重定向的英文是 redirect意思是“改变方向”。在 Linux 里重定向的本质是改变某个文件描述符指向的目标。默认 fd 1 指向屏幕你用之后fd 1 的指向就被改成了某个文件于是程序往标准输出写的内容不再上屏幕而是进文件。这里的底层机制是 dup、dup2 这些系统调用在做复制文件描述符的操作。Shell 解析你的重定向语法然后调用底层系统接口让指定的 fd 指向新的文件。理解到这一层你就能解释很多现象比如为什么 file会先清空文件内容再写入因为 Shell 在打开目标文件的时候用的是O_WRONLY | O_CREAT | O_TRUNC这些标志O_TRUNC就是截断把文件原来的内容清掉。而用的是O_APPEND以追加模式打开写入时自动定位到文件末尾。再比如为什么command 2 error.log能把错误信息单独存起来因为只改变了 fd 2 的指向fd 1 还是屏幕。程序打印正常结果走 fd 1 上屏打印错误走 fd 2 进文件。两条通道互不干扰这就是“分而治之”的设计思想。我用一个生活类比帮你加深记忆想象你在一家公司上班公司有两个内部邮箱一个用来收客户的订单标准输出一个用来收客户的投诉标准错误。默认情况下前台会把两边的邮件都送到你办公桌上。但你可以定个规则订单全部转给助理处理投诉转给专门的客服小组2当然你也可以让助理同时处理两边的邮件21。重定向就是你给这些邮件流设定的转发规则。2.3 为什么 Shell 需要这么多符号其实只有三类动作很多命令大全里列出十几个重定向符号看着吓人其实归纳起来只有三类动作第一类是改变输出目标比如、、2、2都是把某个地址的走向改到新位置是覆盖是追加。第二类是复制文件描述符比如21意思是把 fd 2 重定向成 fd 1 当前指向的地方。注意“当前指向”这四个字顺序很关键这个后面专门讲。第三类是特殊丢弃 /dev/null就是把输出丢到字符设备空文件里相当于扔进黑洞。/dev/null很特殊往里面写什么都不会存读出来永远是空。它是 Linux 世界里最常用的“垃圾桶”。至于、这种写法其实是第一类和第二类的语法糖等价写法而已。你把这三类动作记牢再去看任何重定向组合都能拆解成“谁从哪来到哪去”的问题。提示file和file是 Bash 和 Zsh 的扩展语法把标准输出和标准错误同时重定向到文件。但注意在 POSIX sh 和 dash 里不一定支持跨平台脚本建议写 file 21这种兼容性最好的形式。3. 重定向符号全解析每个符号背后的用意3.1与覆盖和追加的正确姿势是重定向里最常用的符号作用是把标准输出写入文件如果文件不存在则创建如果存在则先清空再写入。写脚本时一句echo hello /tmp/hello.txt文件内容就是hello。再执行一次文件还是只有一行hello因为上次的内容被清了。的作用是追加不会清空已有内容。所以日志轮转或者持续采集时你几乎不会用因为每次执行都会把上次的日志清掉。这个区别非常基础但我就见过有同学把监控脚本的输出写成 /var/log/app/status.log跑完一看日志文件里只剩最后一次的结果前面的历史全没了。排查了半天最后发现问题出在覆盖写而不是追加写。实操上有个小建议如果你写的是循环里的日志输出或者会被多次调用的函数默认优先考虑。只有当你明确要生成全新文件、旧内容可以直接丢弃时才用。判断标准非常简单——问自己这个文件如果已经存在里面的历史值还有用吗有用就追加没用就覆盖。另外提醒一点和的右边的文件路径写相对路径时是相对于当前工作目录pwd而不是脚本所在目录。很多新手写脚本时踩过这个坑脚本放在/opt/scripts下用cron定时执行时当前目录是/root结果输出文件出现在/root下面而不是脚本目录。所以写脚本务必用绝对路径或者显式cd到目标目录。3.22与2把错误单独存起来2就是把文件描述符 2 的走向改到文件错误信息写入指定文件而标准输出还是去原来的地方。这样你在终端上只看到正常结果错误被悄悄存进文件。如果没有报错错误文件是空的——注意是空文件文件被创建了但没有任何内容。2同理追加方式把错误存起来。这在做定时任务排查时特别好用你可以在crontab里写30 2 * * * /opt/scripts/backup.sh /var/log/backup.log 21这样正常日志和报错全部进同一个文件按时间顺序混在一起查看时一目了然。这里说一个容易被忽略的点2后面必须紧跟目标中间空格其实可有可无。Linux 的 Shell 解析时支持2/tmp/err.log这种紧贴写法也支持2 /tmp/err.log带空格。但注意不是所有命令都这样比如管道后面跟2就不是重定向到文件而是重定向到跟命令绑定的某个 fd这个在管道实战部分再展开。还要注意2清空文件的行为和一样用O_TRUNC。所以如果你反复运行同一个命令且用2存错误只有最后一次的错误信息还在。想保留多次运行的历史错误用2。3.321为什么必须写在后面顺序是命门这是全篇最值得反复读的一节。21表示把标准错误重定向到标准输出的当前目标也就是“错误跟着输出走”。但这里的“当前目标”是在 Shell 从左到右解析命令时动态确定的。Bash 对重定向的处理顺序决定了结果command file 21先把 fd 1 指向 file再把 fd 2 指向 fd 1 当前指向的位置即 file最终 stdout 和 stderr 都进 file。command 21 file先把 fd 2 指向 fd 1 当前指向的位置此时 fd 1 还是默认的屏幕再把 fd 1 指向 file最终 stdout 进 filestderr 却还是屏幕。很多同学被第二种组合坑过我以为我写了21就能把错误重定向进文件结果文件里只有正常输出错误还是哗啦啦刷上屏幕。原因就是顺序反了21被执行时 fd 1 还没有改变指向它复制到的是“旧的屏幕目标”。所以请记住这句口诀如果你想把标准输出和标准错误都放进同一个文件先改标准输出的方向再复制标准输出的方向给标准错误。永远把21写在最后面。顺便说一句file和file这两个 Bash 扩展语法天生就把两者一起处理不存在顺序问题但为了通用性我个人的习惯是写 file 21在任何 Shell 上都能按预期工作。我见过不少项目里的脚本在 Ubuntu 上跑得好好的迁移到精简版容器默认 /bin/sh 是 dash之后输出行为就变了排查半天才发现是不兼容。能用最通用的写法就别给自己埋雷。3.4,,21到底怎么选 file 21POSIX 兼容所有 Shell 通吃最稳。 fileBash/Zsh 支持简洁但不可移植。 fileBash 的追加模式同时把 stdout 和 stderr 追加到文件。file 21与file在 Bash 中行为一致但file更短、更直观。我自己的选择逻辑如果是交互式终端里随手用怎么顺手怎么来挺香的如果是写要长期维护的脚本一律用 file 21这种兼容性最强的写法并且严格遵守先输出后错误的顺序。团队协作时约定好一种写法能省很多沟通成本。3.5/dev/nullLinux 里的黑洞什么时候用它/dev/null是一个字符设备文件表现为无限接收数据写入的数据直接丢弃读取时永远返回为空。把不需要的输出丢给它是重定向最常见的用法之一。什么时候用比如你执行find / -name *.conf 2/dev/null因为有些目录你没有权限find 会刷一堆Permission denied的报错真实结果夹在中间根本看不清。把 stderr 丢进黑洞屏幕上只剩干净的结果看着舒服很多。还有下载工具、安装命令运行时打印的进度条和一堆警告如果你确定它们不重要 /dev/null 21就是最典型的“静默模式”。但注意静默是把双刃剑。把错误也吞掉之后命令失败的原因也无从查起。新手最常犯的错误就是把一个尚未稳定运行的脚本里的关键命令输出全部丢到/dev/null出问题的时候一脸茫然。我的建议是脚本调试阶段不要用/dev/null吞掉输出先让日志流到文件里等确认稳定了再决定哪些可以丢弃。注意/dev/null也不是万能的。某些程序输出特别频繁每行都追加到文件时如果日志文件没做日志轮转logrotate文件会无限增长。把 stdout 和 stderr 合并重定向到一个文件然后从不清理用不了多久就能撑爆磁盘。我见过真实案例一个监控脚本每 5 秒输出一行运行状态到/root/status.log结果一年下来日志文件膨胀到几十 GB。重定向本身没错错的是没有配套的日志管理策略。这点放到后面避坑专题再细说。3.6tee的妙用一边上屏一边存文件和的问题在于输出改了方向屏幕上看不到了。有时候你想两边都要日志入文件同时终端还能实时看到输出。这时候用tee。tee读入标准输入同时写入标准输出和一个或多个文件。典型的用法是command | tee /tmp/output.log效果是命令的标准输出既显示在屏幕又写进/tmp/output.log。想追加就加-a参数tee -a。tee默认只处理标准输出不处理标准错误。如果想让标准错误也同时进终端和文件需要先用21把错误合并到输出上command 21 | tee /tmp/output.log这里21必须写在管道左边它的作用是让 stderr 顺着管道一起走。注意这个写法和我们前面说的“先改输出、再复制给错误”有区别——这里管道是 Shell 进程间通信的机制fd 1 已经由管道确定所以21把 fd 2 复制到管道目标是为了让两条流都进管道。tee是处理“既要又要”需求的神器编译代码时的日志、部署脚本的执行记录、甚至是监控程序的长时输出都很适合用tee一边展示一边落盘。写脚本时给用户一个--verbose开关在详细模式下用tee输出既方便用户观察又方便追溯是提高脚本易用性的一招。4. 实操过程与核心环节实现4.1 环境准备用什么终端、什么 Shell 来测试在动手之前先确认环境。前面讲了很多 Bash 的扩展语法如果你的 Shell 不是 Bash部分写法可能会行为不同。查看当前 Shell 很简单echo $SHELL通常在 Ubuntu、CentOS 等大多数发行版上默认 Shell 都是 Bash。但如果你切了shdash那就可能不认识了。建议把下面的测试统一放在 Bash 环境下进行。顺便说一下测试最好用普通用户不要用 root因为有些命令无权限报错就是我们需要观察的现象。比如普通用户在根目录下执行ls /root会报Permission denied这就是观察 stderr 行为的天然素材。写测试脚本时建议在~/.bashrc或~/.bash_profile里做一个小优化给PS1变量加上当前目录的展示这样你能随时看到当前工作目录避免重定向文件写到意外位置。说真的绝大多数重定向路径问题根子都在“我以为我在这个目录”。4.2 从最基础开始三条命令看清 stdout 和 stderr打开终端先做三组实验。第一组正常输出和报错同时出现ls /tmp /nonexistent_dir屏幕上你会看到/tmp的文件列表同时还有一行ls: cannot access /nonexistent_dir: No such file or directory。前者是 stdout后者是 stderr。肉眼区分可能看不出来因为默认屏幕上的颜色、字体常常是一样的。第二组只重定向 stdoutls /tmp /nonexistent_dir /tmp/ls_out.txt这时屏幕只剩错误信息而/tmp/ls_out.txt里只有/tmp的内容。注意stdout 的只改变了 fd 1stderr 还是屏幕。这个现象充分证明了 stdout 和 stderr 是两个完全不同、可以相互独立的通道。第三组只重定向 stderrls /tmp /nonexistent_dir 2 /tmp/ls_err.txt屏幕显示正常列表/tmp/ls_err.txt里是错误信息。如果你把两份文件都打开会发现 stdout 和 stderr 的内容各自纯净互不污染。做完这三组实验我相信你已经建立起最基础的认知stdout 是“程序的答案”stderr 是“程序的抱怨”重定向就是在选择让哪部分去哪里。很多时候理解不透彻不是因为概念太复杂而是没有亲手看一遍现象。4.3 日志落盘的三种姿势从简单到规范我在实际工作中接触过大量项目的日志输出方式总结出三种典型姿势从简单到规范你可以按项目复杂程度选择。第一种最简单直接command app.log。适合一次性任务、临时检查。缺点非常明显覆盖旧日志、不拆错误排障时信息不全。第二种区分 stdout 和 stderr分别落盘command app.log 2 app.error.log这样正常日志和错误日志分文件存放问题排查时先看 error 文件效率高很多。很多后台守护进程都是这种模式比如 nginx 的 access.log 和 error.log 就是典型。第三种合并落盘保留时间顺序command app.log 21所有输出按时间顺序混在一个文件里。对于大多数应用来说这种方式更实用因为很多程序报错时会先打印上下文接着打印报错原因分开存反而割裂了关联。我自己做脚本时倾向的方案是开发调试阶段用tee -a同时屏幕和文件稳定运行阶段用第三种的合并追加方式如果有敏感信息或者需要做数据统计再考虑把 stdout 单独输出到另一个文件。日志方案的取舍没有银弹核心是要能快速定位问题且文件不会无限膨胀。正则清理日志的小技巧也顺便分享一个配合find和grep可以快速清理几天前的日志。比如find /var/log/myapp -name *.log -mtime 7 -delete这句命令会删除 7 天前修改过的所有.log文件。配合 cron 定时执行日志文件就不会撑爆磁盘。具体原理不复杂find的-mtime 7表示修改时间超过 7 天-delete删除。放在这里讲是因为很多重定向实践最终都离不开配套的日志管理。4.4 管道与重定向配合让命令“接力”管道|是 Linux 命令组合的灵魂。重定向解决的是“命令输出去哪里”管道解决的是“命令输出直接作为下一条命令的输入”。两者经常配合使用。比如统计一个日志文件里错误出现的次数grep ERROR app.log | wc -lgrep 输出的是匹配行通过管道送给 wc 统计行数。这里没有重定向但理解管道的存在有助于理解下面的高级用法。如果想让错误和正常输出都进管道用21command 21 | grep 错误这个写法的意义在于如果只是command | grepgrep 接收到的只有 stdoutstderr 还是会直接打到屏幕上可能导致 grep 漏掉关键报错信息。把 stderr 合并到 stdout 再进管道grep 就能完整地筛选所有输出。再比如你想查看一个命令输出的前几行和最后几行可以这样command 21 | tee full.log | tail -50屏幕上显示最后 50 行因为管道末尾是 tail同时完整输出写入full.log。这种写法在部署脚本中很常用操作者看尾部进度完整日志留作审计。我个人在用管道时有一个习惯命令链越长越要注意管道的哪一侧是哪个 fd。很多同学写command 21 | grep xxx时分不清21是在命令的哪一侧起作用的。实际上21在管道左边是先把左边命令的 stderr 合并到它的 stdout再送进管道如果写在右边比如command | grep xxx 21那是把 grep 的 stderr 合并到 grep 的 stdout跟左边命令的 stderr 毫无关系。方向搞反输出行为会完全不一样。判断方法很简单看语法字节在哪个命令后面它就作用于哪个命令。4.5 脚本实战一个带完整日志策略的部署脚本理论讲完上实战。下面我用一个实际的部署脚本 Demo 来展示重定向在真实场景中怎么用。这个脚本执行的是一个假想的部署流程拉代码、跑测试、重启服务、检查健康状态。完整的日志策略应该是每个步骤的日志都落到独立文件同时保留全量日志最后汇总一个结果摘要。#!/usr/bin/env bash set -euo pipefail LOG_DIR/var/log/myapp_deploy FULL_LOG${LOG_DIR}/deploy_$(date %Y%m%d_%H%M%S).log ERROR_LOG${LOG_DIR}/deploy_error.log mkdir -p ${LOG_DIR} echo 部署开始 $(date) | tee -a ${FULL_LOG} log_info() { echo [INFO] $* | tee -a ${FULL_LOG} } log_error() { echo [ERROR] $* | tee -a ${FULL_LOG} 2 } # 步骤 1拉取最新代码 log_info 拉取代码 if git pull origin master ${FULL_LOG} 21; then log_info 代码拉取成功 else log_error 代码拉取失败 exit 1 fi # 步骤 2运行测试 log_info 运行单元测试 if make test ${FULL_LOG} 21; then log_info 测试通过 else log_error 测试失败日志见 ${FULL_LOG} exit 1 fi # 步骤 3重启服务 log_info 重启服务 sudo systemctl restart myapp ${FULL_LOG} 21 if systemctl is-active --quiet myapp; then log_info 服务已重启 else log_error 服务重启失败 exit 1 fi log_info 部署完成这个脚本里的关键点第一set -euo pipefail是 Shell 脚本的三保险。-e表示出现任何非零退出码时立即退出-u防止使用未定义变量-o pipefail让管道命令组中任何一个失败都算失败。很多脚本混乱的根源就是不设这三条。注意tee -a ${FULL_LOG} 2这一行的妙处既把错误信息追加进全量日志又让它以 stderr 形式输出到屏幕调用方如果用21捕获这个脚本的输出错误信息也能被正确转发。第二每条命令的重定向目标都指向同一个FULL_LOG用追加模式。这样做的好处是全量日志顺序清晰每个步骤的上下文都在。而 error 文件不是直接由命令写入而是 log_error 函数用 tee 追加——这么做是为了将业务层面的错误和信息分开方便监控系统只抓 error 文件。第三判断命令是否成功用的是if ... then ... else模式。这里不能省略21否则 git 或 make 的错误信息会直接打在屏幕上既破坏了全量日志的完整性也可能被 cron 的环境忽略掉。把错误并入日志后无论手动运行还是定时任务行为都完全一致。这个脚本不是 100% 面面俱到但核心的日志策略体现得很清晰全量日志、错误日志、控制台输出三层分离每一步的关键事件都有记录。你在设计自己的脚本时按这个结构去套基本不会出大问题。4.6 高级技巧exec 重定向、临时切换 fd、进程替换除了逐条命令重定向你可以用exec在脚本级别统一改变文件描述符。exec logfile这条语句会把当前 Shell 脚本的整个标准输出重定向到 logfile之后的每条命令输出默认都进文件直到脚本结束。同理exec 2 errfile可以把后续所有错误重定向到错误文件。这种方式在写大型脚本时很实用不用每条命令都带重定向。复原默认输出用exec /dev/tty这个有点冷门但确实存在需求。要注意用了exec重定向之后如果脚本中途需要把某条命令的输出送回屏幕要么临时存一下 fd要么显式指定。暂时保存 fd 的写法是exec 31 # 打开 fd 3让它指向当前 stdout exec logfile # 标准输出重定向到 logfile ... echo 这行进 logfile ... exec 13 # 把 stdout 恢复成 fd 3 指向的地方也就是终端 exec 3- # 关闭 fd 3fd 31的写法本质上是把 fd 3 复制到 fd 1 的当前位置保留了原来的输出目标。这是前面讲的复制文件描述符原理的实际应用理解之后你就能自己“发明”各种输出方案。另一个实用技巧是进程替换(command)。比如你想比较两个命令的输出而不想创建临时文件diff (ls /etc) (ls /usr/local/etc)(...)会让 Shell 启动一个子进程运行命令并把它的输出通过管道暴露为一个临时文件描述符diff 把两个进程替换当作文件来比较。这个功能跟重定向同属输入输出重定向范畴虽然不涉及写法但理解它的底层机制对整体把握重定向非常有帮助。4.7 安全与权限重定向文件最容易踩的坑重定向本身不复杂但和权限结合时会有一堆坑。最常见的是你重定向的目标文件所在的目录没有写权限Shell 在打开文件时失败会报Permission denied。但注意这个报错本身是 Shell 报的它走的是 fd 2也就是默认的 stderr。所以如果你写的是command no_perm_dir/out.log 21有条隐藏逻辑21在 Shell 打开文件失败之前就已经被解析了实际上报错的序列可能有点反直觉但核心记住一点重定向动作是 Shell 执行的不是命令执行的命令看不到重定向错误。再看一个经典权限问题sudo command /root/out.log为什么经常报Permission denied因为sudo只让 command 命令以 root 运行但重定向是由当前 Shell 完成的它以自己的身份尝试打开/root/out.log没有权限Shell 直接报错。正确的做法是sudo sh -c command /root/out.log或者command | sudo tee /root/out.log /dev/null第二种方案的原理是命令以普通用户身份运行输出通过管道进入sudo teetee 以 root 权限打开文件并写入。这个写法在需要保留原始命令状态时非常实用我日常用的最多因为它避免了sudo sh -c引号嵌套的麻烦。另一个容易踩坑的是路径里的空格。如果你重定向的文件路径包含空格必须用引号括起来否则 Shell 会把路径拆开。比如echo hello /tmp/my file.txt会创建两个文件一个叫/tmp/my一个叫file.txt。正确写法是echo hello /tmp/my file.txt。这个错误低级但极其常见尤其是 Windows 转 Linux 来的同学经常踩。最后提一下noclobber选项。Bash 的set -o noclobber开启后在文件已存在时会报错而不是覆盖防止误操作。适合需要严谨保护的场景比如初始化脚本里不想重复覆盖配置文件。要用强制覆盖就写|比如echo xxx | file这是跟 noclobber 配套的写法。5. 常见问题与排查技巧实录遇到重定向问题怎么办5.1 六个高频坑我踩过你也可能踩第一个坑21写错位置。前面说过command 21 file和command file 21行为完全不同。如果在脚本中发现文件里日志缺失、错误全在屏幕上先检查21是否在最后面。第二个坑日志文件没有被创建。可能不是重定向语法问题而是目标目录不存在。Shell 打开文件时不会自动创建目录——mkdir 是必须的。写脚本时先mkdir -p是个好习惯。第三个坑覆盖写了历史日志。确认你用的是而不是。如果你用了且系统开了 noclobber可能直接报错日志没写进去。如果没开 noclobber历史日志就悄悄没了没有任何提示。第四个坑日志文件无限增长。没人清理、没有 logrotate、脚本高频输出磁盘被撑爆。这个前面提过我这里想强调日志管理必须和日志生成同步设计不要等出事再补。第五个坑管道和重定向顺序理解错误。cmd 21 | grep xxx和cmd | grep xxx 21看起来很像结果完全不同。前者把 cmd 的 stderr 合并进管道后者只是把 grep 自己的 stderr 合并到 grep 的 stdout。排查管道行为异常时先区分 stderr 到底属于哪个命令。第六个坑cron 任务输出找不到。cron 默认把未重定向的输出通过邮件发给 root或 MAILTO 指定的地址不会出现在任何日志文件里。很多人配了 cron 之后发现没有日志可查因为根本没重定向到文件。cron 场景下最好显式写 logfile 21。5.2 排查重定向问题的思路从现象反推出问题时不要急着怀疑命令本身。先判断几个问题命令退出码是多少输出到底去了哪里文件权限对不对我建议建立一套排查清单直接用不带重定向的命令看默认输出确认命令本身能产生预期内容。拆掉管道单独测重定向观察文件是否创建、内容是否符合预期。检查目标文件是否存在、权限是否允许读写。检查当前目录是否为预期目录避免写成相对路径而实际在另一个位置。检查 Shell 类型是否匹配语法特性。Bash 特有的语法切到 sh 下可能完全失效。如果是 cron 里跑把命令原样复制到终端跑一遍对比行为差异。cron 环境变量极少PATH 可能都不是你期望的路径。这套思路本质上就是“逐步缩小范围”。重定向是 Shell 层面的行为命令本身是无辜的找到“Shell 究竟把 fd 指向了哪里”是最核心的一步。调试 fd 指向还有一个黑魔法给当前 Shell 的 fd 1 和 fd 2 各挂一条尾巴做个“镜像”。但这不是日常必须知道有这个思路即可。5.3 快速自查速查表常见需求对应的写法下面这张表是日常使用频率最高的组合建议直接收藏结合实际场景验证后变成你自己的“肌肉记忆”。需求推荐写法说明把 stdout 保存到文件覆盖cmd file会清空 file 原有内容把 stdout 追加到文件cmd file保留历史内容把 stderr 保存到文件cmd 2 filestdout 仍在屏幕stdoutstderr 一起进文件覆盖cmd file 21顺序重要stdoutstderr 一起进文件追加cmd file 21curl、wget、脚本日志常用stdoutstderr 一起丢弃cmd /dev/null 21静默执行保留 stderr丢弃 stdoutcmd /dev/null正常输出丢了报错留着保留 stdout丢弃 stderrcmd 2 /dev/null只留正常结果屏幕文件同时输出cmd | tee file只有 stdout屏幕文件含 stderrcmd 21 | tee filegrep、脚本日志推荐要求 root 写文件cmd | sudo tee /root/out.log /dev/null避免 sudo 重定向无效问题这张表的核心价值在于每个需求对应一行清晰直给。如果你想更深入理解为什么是这个写法回到前面第三、第四小节的内容去对照。5.4 避免重定向造成事故的三个习惯说一句大实话重定向本身不是事故源头无视重定向后果的操作习惯才是。我见过的最吓人的事情是用把配置文件覆盖成空文件因为原本想写追加。好在文件小还能临时用编辑器恢复。但数据库配置文件、密钥文件这种核心资产被误清代价就是无法估量的。所以我有三个硬习惯第一对重要文件做任何覆盖写之前先确认文件是否存在、内容是否有价值。可以用test -f file echo exists也可以直接ls -l看大小。如果历史内容珍贵改用追加或者先cp留个备份。第二尽量别把重定向的目标路径写成当前目录下的短名字比如 log.txt。手动执行时你在家目录还好脚本里被 cron 拉到其他目录跑输出就跑到意想不到的地方。显式写全路径哪怕丑一点也比排查半天下不去手强。第三使用set -o noclobber保护那些你不允许覆盖的文件。开启后遇到已存在文件时直接报错逼你确认意图。命令行想强制覆盖时用|这个符号不那么顺滑反而是一种“主动操作”的提醒。5.5 从重定向延伸到系统编程内核角度看一眼 fd最后做个扩展。开头提到 Linux 一切皆文件重定向的底层是 dup/dup2。如果你想在 C 语言里实现“备份原输出改到文件再恢复”本质上就是你可以在 Shell 里用 fd 3 保存恢复目标然后把 stdout 重定向到文件最后再把 fd 3 复制回去。系统调用层面dup2(fd, 1)就可以把 fd 1 指向 fd 所描述的文件。顺带一提如果你在做内核模块或驱动开发比如网上常见的热搜“linux 内核 动态加载 file_operations 拦截 read write”这些工作本质上也是在跟文件操作结构打交道。应用层重定向让用户态程序输出到任意文件内核层 file_operations 决定这个文件的数据最终怎么被读写。理解用户态的重定向会让你看内核相关代码时更有画面感。嵌入式 Linux 场景也是重定向的重灾区。很多嵌入式系统没有显示器全靠串口输出日志。启动脚本里consolettyS0之类的参数本质上是把内核输出重定向到串口设备。你自己在嵌入式板子上跑程序时用 /dev/ttyS0把输出导到串口也是同样的机制在起作用。重定向在嵌入式调试中的价值一点不亚于服务器场景。5.6 对话中的一个小技巧实时监控重定向后的日志写脚本调试时经常需要一边跑程序一边看日志文件是否在更新。两个好用的命令tail -f file和less F file。tail -f会持续输出文件的增量内容适合观察不断追加的日志。less F是 less 的“跟随模式”按CtrlC暂停按F恢复比 tail 更灵活。它们不是重定向功能但和重定向配合使用能极大提升排查效率。比如你在跑一个长时间的任务命令输出重定向到了deploy.log想实时观察最新进度同时保留历史完整记录可以再开一个终端窗口tail -f /var/log/myapp_deploy/deploy.log这个组合是我日常干活的最常用套路一个终端跑任务一个终端看日志。看到报错立刻用CtrlC停掉任务进入排查。6. 写在最后的一点经验重定向这个主题说大不大说小不小。很多人用了十年 Linux天天见21却从没认真想过它为什么这样写。我当年也是照着复制、用着出坑、再搜答案来回折腾了很久才完全通了。现在回头看真正让我豁然开朗的并不是某个符号记住了而是把“文件描述符”这条底层线索抓在手里一切重定向都是文件描述符的重新指向理解了这一层剩下的全是推导。我自己用重定向最多的地方除了日常命令就是写部署脚本和定时任务。几乎所有长时间运行的脚本我都会设计一套日志策略全量日志、错误日志、输出控制三件套。这套方法论帮我节省的排查时间真的难以估量。如果你看完这篇文章只带走一个东西我希望是这句话设计脚本时先想清楚三类人去哪再写命令。输出方向不确定的脚本早晚是个隐患。另外分享一个小技巧在.bashrc里我可以设置export PROMPT_COMMANDecho $(date %H:%M:%S) $(pwd) /tmp/shell_history_debug.log这是把终端本身的操作记录重定向到日志文件。如果你想复现某个“我也不知道什么时候执行的命令”导致的问题这个技巧能帮你留下痕迹。虽然有点啰嗦但关键时刻能救命。就用这些最实用的经验收尾吧。重定向只是 Linux 体系里的一个小环节但搞定它之后对整个 Shell 模型的理解都会上一个台阶。希望这篇文章能帮你补上这块拼图。