在Linux下敲命令最常被忽略却又最要命的就是标准输出和错误重定向。你可能遇到过这种情况脚本里明明写了输出日志结果排查问题的时候日志文件干干净净真正的报错全在终端上飘着或者定时任务跑完根本没留下任何痕迹出了问题只能干瞪眼。这套东西搞不明白写多少行脚本都等于在裸奔。这篇东西不扯虚的直接从文件描述符讲起把标准输出、标准错误、重定向符号的底层逻辑捋一遍再给出一套可以直接抄的日志收集方案和排查套路。适合刚接触Linux的初学者也适合写了不少脚本但总觉得日志管理不顺手的运维和开发。1. 先搞懂Linux的“三道闸门”标准输入、标准输出与标准错误1.1 进程眼中的0、1、2到底是什么Linux里一切皆文件进程和外部打交道靠的是文件描述符file descriptorfd。每个进程启动的时候系统默认给它打开三个文件描述符0号是标准输入1号是标准输出2号是标准错误。这三个编号就是进程和外界交互的三条通道操作系统的文件描述符表就像一个门牌号登记册进程拿着编号就能找到对应的文件流。很多初学者会卡在这里既然标准输出和标准错误都能在屏幕上显示那设计两个通道有什么意义我举个例子你就明白了。假设你运行一个编译命令正常编译日志和warning都走标准输出而编译失败的error走标准错误。如果你只想把出错信息存下来直接2 error.log就行不需要把几百行正常日志也拖下水。这就是Linux把两个输出通道分开的核心原因——日志和错误各自归位后续处理互不干扰。你还可以在命令后面加1或者2来查看描述符指向的目标比如ls /proc/self/fd能看到当前shell打开的fd情况。不过这个命令对新手可能有点抽象真正实用的方式是直接拿重定向测试echo hello /dev/null屏幕上什么也没有但echo hello 2 /dev/null时hello还会照常显示。这就是1号通道被截走、2号通道原样保留的结果。1.2 屏幕只是默认出口不是唯一出口终端、管道、文件对Linux来说都是一种“文件”所以标准输出默认指向终端并不代表它只能指向终端。你用符号把1号通道重定向到文件就是让输出从“流向屏幕”改成“流向文件”。同理管道符 |本质上是把前一个命令的标准输出接到后一个命令的标准输入上。这里有个特别容易踩的坑很多人以为管道只传递标准输出不传递标准错误。确实如此。cmd | grep abc抓不到cmd的标准错误输出错误会直接打到屏幕上。所以想过滤报错内容你得先21把标准错误合并进标准输出再丢给管道。这个在后面章节会详细展开但你现在要记住一个核心概念重定向不是把输出“复制”一份过去而是改变输出的流动方向原来的出口就被替换掉了。屏幕上看到的内容其实是两个通道各自输出的合流。如果你把标准输出重定向到了文件屏幕上就只剩下标准错误在“裸奔”如果两个都重定向了屏幕上就什么都没有了。这个认知是整个重定向体系的地基。2. 最常用的重定向操作符实战、、2与合并技巧2.1与的区别覆盖还是追加是最基础的重定向符号作用是把标准输出写入指定文件注意是覆盖写入。文件原本的内容会被清空如果文件不存在则创建。这个特性在生产环境里非常危险因为只要写错一次文件名原来的日志文件就没了。所以我在操作前都会下意识确认目标路径尤其是root权限下覆盖一个系统关键文件可能直接让服务起不来。是追加重定向把标准输出追加到文件末尾不清空原有内容。写日志、记录脚本执行历史都推荐用这个它能保证多次运行的结果累积在一个文件里方便按时间顺序回溯。绝大多数生产脚本里日志输出都应该用追加模式而不是覆盖模式否则每次执行脚本都会把上一次的日志抹掉等于白记录。给你一个对比实验一眼就能看出两者区别# 第一次写入 echo 第一行 test.log # 覆盖写入test.log只有这一行 echo 第二行 test.log # 追加写入test.log有两行 echo 第三行 test.log我第一次带新人的时候就让对方反复敲这个例子。很多初学者会以为带点智能能自己判断该覆盖还是追加实际上它就是个没脑子的写入动作只有才带“续写”属性。2.22单独捕获标准错误既然1号通道是标准输出2号通道是标准错误那么2就专门把标准错误重定向到文件。最经典的场景是编译代码时保留错误信息gcc main.c -o main 2 error.log这样编译成功的输出还在终端上而error.log里只存编译报错。如果换成 error.log则只存正常输出报错还是会打到屏幕上排查问题的时候根本找不到关键信息。很多人在处理报错时习惯性用 log 2 log但这其实有个隐患两个文件描述符指向同一个文件写入时互相覆盖日志内容会错乱正确的做法是 log 21让标准错误直接复用标准输出的文件描述符。单独捕获错误还有一个妙用就是用来判断命令是否执行成功。比如if ls /no/such/path 2/dev/null; then echo 目录存在 else echo 目录不存在 fi这里把错误丢弃只靠命令的返回码判断分支。很多脚本里用这种方式探测路径、检查进程是否存在配合2/dev/null可以屏蔽掉一堆噪音信息。2.321与合并输出通道的正确姿势21的意思是把标准错误重定向到标准输出当前指向的地方重点是“当前指向”。因为shell解析重定向是从左到右顺序处理的所以command file 21和command 21 file的执行结果完全是两码事。先看正确写法command file 21执行顺序是先把1号通道指向file再把2号通道指向1号通道当前的指向也就是file。最终标准输出和标准错误都进了file。再看错误写法command 21 file执行顺序是先把2号通道指向1号通道当前的指向此时1号还指向终端所以2号也指向终端接着再把1号通道指向file。最终标准输出进了file标准错误还是打在屏幕上。这个细节坑了无数人。我见过很多脚本里写着command 21 file然后怎么调试都觉得代码没毛病结果报错全部飘在终端上日志文件永远是空的。你只要记住一个口诀合并输出先改1后指2 file永远写在21前面就不会出错。是Bash提供的简写形式command file一步到位把标准输出和标准错误同时重定向到file。它不需要保证顺序因为语法层面就注定了两者都指向同一个文件。同理追加版本。这个写法简洁但可读性稍差有时候你在别人的脚本里看到如果不熟悉可能反应不过来所以我个人在正经脚本脚本里还是习惯写 file 21意图更明确。3. 重定向的解析顺序与文件描述符的本质3.1 shell是从左到右处理重定向的前面已经提到shell解析命令行里的重定向遵循从左到右的顺序。这个特性导致的结果就是同一个命令换个顺序行为可能天差地别。除了21的例子再来看一个输入重定向的陷阱command input.txt output.txt这个写法很常见先指定输入文件再指定输出文件没有问题。但如果你把顺序倒过来command output.txt input.txt效果其实也是一样的因为输入和输出是两个不同的方向互不干扰。但输出重定向之间就要小心了command a.txt b.txt这种情况下后一个会覆盖前一个最终只有b.txt会被写入a.txt会被创建成空文件。对于初学者来说这种层层覆盖的行为可能显得“不讲道理”但理解了shell的顺序解析机制就能明白每个重定向修改的都是文件描述符表中对应编号的指向最后一次修改生效。当你在命令里同时使用多个重定向时可以想象成在做一系列“重新接线”的操作。管道也是一样命令从左到右依次执行前一个的输出作为后一个的输入。理解整体顺序比死记硬背每个符号怎么用更重要。3.2 文件描述符是“指向”而非“绑定”文件描述符表中的每一项本质是一个指向打开文件描述的指针。你用 file把fd1指向file对应的文件再用21把fd2也指向同一个文件描述这时候fd1和fd2就是同一个文件描述的两个别名往任何一个写入都会作用在同一个偏移位置上。这就解释了为什么 file 21写入时不会互相覆盖因为fd1和fd2共享同一个文件偏移写日志的顺序和原始输出顺序完全一致。而如果写成 file 2 fileshell会分别打开file两次得到两个独立的文件描述符它们各自维护自己的偏移写入时会发生相互覆盖最终文件里的内容可能是乱序的甚至丢失数据。我见过有人为了图省事写cmd log 2 log还觉得自己没毛病结果排查了好几个小时最后发现日志内容错乱就是因为这个。正确做法永远是用21合并到一个文件描述符而不是用两个重定向指向同一个文件名。3.3 /dev/null价值连城的“黑洞”/dev/null是一个特殊的设备文件写入它的数据会被系统直接丢弃读取它则立即返回EOF。很多人把它当成“垃圾场”但其实它在脚本里有很多高级用法。比如你只关心命令是否执行成功不关心输出内容if command /dev/null 21; then echo success else echo fail fi再比如你想在不影响终端显示的情况下把错误丢弃find / -name *.conf 2/dev/nullfind在搜索无权访问的目录时会疯狂输出权限错误全部丢弃之后屏幕能清爽不少。我在排查系统问题时经常用这个组合既能隐藏噪音又不影响真实的搜索结果。很多人觉得丢弃输出是一种浪费但在自动化运维里很多时候我们只关心“命令成没成功”输出内容反而干扰判断丢掉是明智的。另外/dev/null还经常用来清空文件内容cat /dev/null huge.log这样能瞬间把大日志文件清空同时保留文件inode和权限不会中断正在写这个文件的进程。如果要比较严谨地清空文件还能用truncate -s 0 huge.log效果类似但对新手来说cat /dev/null 更好理解。4. 从入门到实践日志记录与脚本执行的完整方案4.1 tee命令把输出同时送到屏幕和文件有时候你希望保留日志文件但也想实时在屏幕上看到输出。用cmd log 21会把屏幕完全让给别的窗口而用tee可以一箭双雕cmd 21 | tee -a logtee会把标准输入原样写入文件同时复制一份输出到标准输出-a是追加模式。这样你既能看到实时输出又留了完整日志。这里有个细节上面的命令只对标准输出做了tee处理标准错误呢21已经把它合并到标准输出顺着管道进了tee所以日志里能保留全部信息。如果漏了21报错还是会直接打到终端不经过tee。tee还有一个进阶玩法用在需要超级权限写入文件的时候。比如普通用户想追加内容到root拥有的文件echo new line | sudo tee -a /etc/hosts直接用sudo echo new line /etc/hosts往往会因为重定向操作发生在sudo之外而失败因为重定向是由当前shell执行的不是由sudo执行的。tee方案则绕过这个限制既保持命令行的直观性又满足权限要求。4.2 写脚本时如何统一管理日志输出写bash脚本时最烦的就是每条命令后面都要挂重定向。一个简单的办法是在脚本开头加上#!/bin/bash exec /var/log/my_script.log 21exec命令不带参数执行重定向时会直接修改当前shell进程的文件描述符。这样一来脚本里所有的标准输出和标准错误都会自动追加到指定日志文件后面不用再写任何重定向了。这个方法我用了很多年极大地简化了脚本编写。你只要记住exec重定向会持续到脚本结束如果你中途想恢复终端输出可以用exec /dev/tty重新把标准输出指向当前终端。不过一般情况下也没必要恢复日志文件里看就够了。还有一点值得注意如果你用cron运行脚本cron的环境和交互式shell不同环境变量可能缺失输出默认会通过邮件发给本地用户。引入exec 重定向后所有日志自然落盘也不再产生多余的邮件干扰简直是配合cron的绝配。4.3 定时任务日志看不到内容怎么办很多人在cron里写了脚本跑完之后却发现日志文件是空的排查半天也找不到原因。这种问题十有八九出在两个地方一个是环境变量另一个是重定向顺序。先说环境变量。cron运行的shell是非登录、非交互式的不会加载/etc/profile和~/.bash_profile里的环境变量。你在终端里能用的命令在cron里可能直接“command not found”。解决办法是脚本开头显式指定PATH#!/bin/bash export PATH/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin或者直接在cron里设置* * * * * /usr/bin/bash /opt/scripts/myscript.sh /tmp/myscript.log 21这里还有个关键点cron执行命令时默认的shell可能是/bin/sh而不是/bin/bash某些bash特性比如可能不生效。保险起见最好脚本开头写上#!/bin/bashcron里调用时也用bash显式执行。再说重定向顺序。如果你写的是cmd 21 file前面分析过报错不会进文件cron邮件里反而能看到一堆错误信息。如果配置了cron不发送邮件比如设置了MAILTO那系统直接静默丢掉这些错误看起来就像“啥也没发生”。4.4 输入重定向的应用场景标准输入重定向在日常运维里用得不如输出重定向多但它也有不可替代的价值。最典型的是从文件读取内容执行命令mysql -u root -p init.sql这个命令把init.sql的内容作为mysql命令的输入完成数据库初始化。如果不重定向你就得手动一条条输入SQL又慢又容易出错。另一个常用场景是把字符串传给命令cat hello world是一种here string相当于把字符串作为标准输入传给命令。配合wc -c、md5sum这类命令做简单计算非常好用比如md5sum test会直接输出test字符串的md5值不用先echo到文件再去读。如果你需要多行输入可以用here documentcat EOF config.txt key1value1 key2value2 EOF这种写法在生成配置文件时特别顺手脚本里可以轻松创建一段多行文本。和多条echo拼接比可读性提升了好几个档次。5. 常见问题与排查技巧实录5.1 日志丢失、错乱、顺序颠倒的根因整理一下我实际踩过和帮别人排查过的常见问题你会发现大部分都能归到文件描述符指向混乱上。现象可能原因正确姿势日志文件为空错误还在终端写成了21 file file 21日志内容乱序或覆盖用了 log 2 log log 21日志只记录了部分输出程序往标准错误写你用重定向加上21cron脚本无任何输出环境变量缺失或没重定向显式PATH脚本开头exec重定向tee命令没记录到报错漏了21管道前先合并输出这张表我建议截图存下来。很多看起来玄学的问题底子还是重定向那几行代码。遇到日志异常第一反应不是去看程序逻辑而是先把输出链路的描述符指向捋一遍。5.2 用strace追踪进程默认输出当重定向问题特别隐蔽比如某个子进程自己篡改了文件描述符普通的排查手段就乏力了。这时候可以请出系统调用跟踪工具strace看进程实际打开和写入的文件描述符。比如你要排查一个用system()调子命令的C程序它的输出到底流向哪里strace -f -e traceopenat,dup2,fcntl ./my_program-f跟踪子进程-e限制只追踪文件描述符相关的系统调用。从输出里你能看到程序在哪一步调用了dup2把fd1重定向到了哪个文件是哪一行代码造成的日志丢失一目了然。说实话这个工具平时很少用但一旦用上基本都能定位到问题。另一个轻量级排查技巧是ls -l /proc/pid/fd/查看指定进程当前打开了哪些文件描述符以及它们指向哪里。如果你怀疑某个进程的输出位置不对可以实时查看它1号和2号fd的软链接指向。/proc虚拟文件系统在调试中价值很大别把它只当成系统信息展示。5.3 环境变量和shell类型对重定向的影响激进的脚本如果在cron里跑挂先检查它用的shell是/bin/sh还是/bin/bash。Debian系的/bin/sh其实是dash特性比bash少得多这种写法在dash里就不认识。所以跨环境复用的脚本要么用可移植性最强的 file 21写法要么在脚本shebang里强制#!/bin/bash并且用bash显式执行。还有一点非交互shell里source /etc/profile可能无效需要确认PATH是否完整。我曾经遇到一个脚本在终端跑得好好的一进cron就报找不到python就是因为她把python的路径加到了~/.bashrc里但cron根本不读这个文件。后来改成在脚本里显式export PATH才解决。5.4 彻底丢弃输出的场景不是所有输出都要保留。安装软件、加载内核模块这种操作输出里可能一半是warning一半是进度条存下来也没人看。这时直接把所有输出丢给黑洞apt-get install -y nginx /dev/null 21脚本里用起来特别干净。我这里强调一下丢弃前先确认命令确实不需要输出里的关键信息比如某些命令会把密码提示写在标准错误里你全丢了一不小心就卡在等待输入上。可以用timeout 10配合验证命令是否长时间没有输出避免脚本假死。6. 一套可以直接套用的日志管理模板6.1 通用脚本模板最后给出一套我写脚本时常用的模板你结构调整后直接改几行就能用#!/bin/bash set -euo pipefail # 日志目录 LOG_DIR/var/log/myapp mkdir -p $LOG_DIR LOG_FILE$LOG_DIR/run_$(date %Y%m%d_%H%M%S).log # 所有输出走日志 exec (tee -a $LOG_FILE) 21 echo 脚本开始执行 # ... 你的业务逻辑 ... echo 脚本执行完毕set -euo pipefail在脚本出错时能立刻终止执行避免一路错下去产生更多垃圾输出。exec (tee ...)这个写法有点技巧它把标准输出接到进程替换的管道上tee负责同时把内容写入文件和实时打印。date命令生成带时间戳的文件名每次运行一个独立日志文件排查问题非常方便。如果你希望所有运行记录都在同一个文件里把日志文件名改成固定值并给exec重定向加代替但建议还是按天分文件否则日志文件越来越大后期查询很痛苦。6.2 日志轮转的粗浅做法日志文件不可能无限增长Linux自带的logrotate是标准方案。举个例子在/etc/logrotate.d/myapp里写/var/log/myapp/*.log { daily rotate 7 compress missingok notifempty }意思是每天轮转一次保留最近7份旧日志gzip压缩。这样日志管理基本就不用操心了。如果你没用logrotate也可以直接在脚本里加一个清理逻辑删除7天前的日志文件。find $LOG_DIR -name *.log -mtime 7 -delete放在脚本开头或结尾执行效果也不错只是缺少压缩和原子轮转这些细节。生产环境建议还是用logrotate这类成熟工具。6.3 我在实际项目里总结的小习惯输出重定向这个知识点本身不难但真正写项目时细节决定成败。我再说几个自己的习惯供你参考。第一凡是会写文件的命令一律使用绝对路径。重定向文件路径相对于当前目录脚本如果被cron切换了工作目录你以为写到/opt/app结果生成了临时目录的一堆垃圾文件日志找不到排查还得绕一圈。绝对路径能省掉这种低级事故。第二重要脚本开头先ping一下日志文件是否可写。比如if ! touch $LOG_FILE; then echo 无法写入日志文件 2 exit 1 fi如果权限或者磁盘问题导致日志写不进去脚本至少会留下一条明确错误而不是静默失败。很多线上排查难题的根源其实是最基础的“日志没写进去”。第三调试时多用set -x配合重定向。在脚本开头加set -x脚本会把每条执行的命令打印到标准错误配合21输出到日志文件你能看到自己的脚本走到哪一步才出错的比口算快多了。至于说把每次执行的命令记录下来我偶尔还会在脚本里加一句echo [$(date)] 执行命令: $* $LOG_FILE把参数也记下来后期追踪谁在什么时间改了什么参数往往能省下大把时间。学完这些内容建议你打开终端把示例命令逐一跑一遍光看不练很容易陷入“好像懂了但命令一敲就错”的尴尬。标准输出和错误重定向是Linux操作里最基础的技能但也是排查问题最有力的工具用熟了再复杂的任务都能稳住。