凡人修云传（三：重定向管道和tee）

1. 三大流派：stdin、stdout、stderr的江湖地位

在正式开始之前，先讲个段子。当年我刚接触Linux的时候，看着命令一行一行跑完，屏幕上冒出一堆文字，我一直以为这是命令的“回应”。直到有一天，我把一个命令的输出重定向到了文件，结果屏幕上还是哗啦啦地冒出一堆东西，我当时就懵了：我不是已经把输出写到文件里了吗，怎么还在刷屏？

后来才搞明白，Linux下任何命令向外吐东西，其实有三条通道，而不是一条。

• 标准输入（stdin，文件描述符0）：命令从哪儿读数据，默认从键盘读。
• 标准输出（stdout，文件描述符1）：命令把正常结果往哪儿写，默认写到屏幕。
• 标准错误（stderr，文件描述符2）：命令把报错信息往哪儿写，默认也是写到屏幕。

这三条通道，就是Linux世界里最基础的“三大流派”。它们默认都指向终端，但我们可以通过重定向、管道、tee这些手段，任意改变它们的流向。

理解这三者的区别，是理解后面所有操作的前提。很多新手刚接触shell时，最大的认知障碍就是：以为“输出”就只有一种，其实正确结果和错误信息是分开走的。举个例子：

bash复制ls /etc/passwd /etc/not_exist_file

执行结果里，/etc/passwd那行是正常输出（stdout），而ls: cannot access '/etc/not_exist_file'那句是错误输出（stderr）。它俩都打在屏幕上，但来源不同。如果你只把stdout重定向到文件，错误信息还是会直接怼到屏幕上；如果你只把stderr重定向到文件，正常结果又会漏出来。明白了这一点，你才能真正掌控命令的输出行为。

而管道和tee，本质上都是在操作这三条通道的流向。管道负责把一个命令的stdout接到另一个命令的stdin，tee则负责在管道中间开一个口子，把流过的数据分身一份保存下来。

今天这篇文章，就用修仙的比喻把这些东西彻底讲透。你可以把每个Linux命令想象成一个修炼者，stdout是它吐出的一口真气，stderr是它憋不住吐出来的一口老血，而重定向、管道、tee就是控制这些气流走向的经脉和法门。

2. 重定向：基础中的基础，但细节多到能坑死人

2.1 输出重定向：> 和 >> 的差别

先说最常用的>和>>，它们都是把标准输出指向文件，区别在于一个是覆盖，一个是追加。

bash复制# 把date命令的输出写入time.txt，如果文件已存在则覆盖
date > time.txt

# 把uptime的输出追加到time.txt末尾，不会清空原内容
uptime >> time.txt

这个太基础了，但有几个细节我想强调一下。

第一，>和>>如果文件不存在，都会自动创建文件。我见过不少同学以为必须先touch一下文件才能重定向，其实完全没必要。

第二，>的覆盖行为是不可逆的。如果你本来有个重要的配置文件，执行了echo "hello" > config.conf，那就真没了。所以我在生产环境操作时，有个习惯：凡是涉及覆盖已有重要文件的重定向，先用ls -l看一眼，或者干脆改用>>，确保不会误伤。

第三，重定向符号和命令之间的空格问题。date > time.txt写成date >time.txt、date> time.txt都没问题，但为了可读性，建议统一带空格。不过要注意，>time.txt如果紧跟命令名后面，有的shell解析起来会有歧义，虽然bash能处理，但少给自己挖坑。

2.2 错误输出重定向：2> 和 2>>

2>就是专门把标准错误重定向到文件。这在脚本和定时任务里是标配，几乎每一个crond配置或者systemd timer里都会见到。

bash复制# 只把错误信息存下来，正常输出不要
./deploy.sh 2> error.log

# 把正常输出和错误输出分别存到不同文件
./deploy.sh 1> success.log 2> error.log

# 把错误信息追加到日志文件
./deploy.sh 2>> deploy.log

为什么要把错误和正确分开？因为排查问题时，你只想看报错信息，不想在一堆正常日志里翻找。而判断一个脚本是否成功，有时候恰恰要靠错误日志来判断。分开存，出问题的时候直接看error.log，效率高得多。

2.3 常见误区：2>&1 到底该怎么写？

这里有一个经典考题：怎么把标准输出和标准错误都重定向到同一个文件？

很多新手会写command > file 2> file，这个写法看起来对，但实际上是个坑。两个文件描述符各自独立打开同一个文件进行写入，带有不同的文件偏移量，在高并发或大量写入时，会互相覆盖内容。正确做法是：

bash复制command > file 2>&1

这个2>&1的意思是把标准错误重定向到标准输出当前指向的位置。注意，它必须出现在> file之后，因为它是“把错误输出指向标准输出的去向”，而标准输出去向要靠前面的> file来指定。

如果你写成command 2>&1 > file，执行顺序会变成：先把标准错误指向屏幕（因为它继承了当前标准输出的位置，即终端），再把标准输出指向文件。结果就是错误信息依然打到屏幕上，完全没有重定向。这个顺序问题，我见过无数人栽过跟头，包括我自己。

bash还提供了一种更简洁的写法：

bash复制command &> file

&>是同时重定向stdout和stderr到文件，不需要区分顺序。在较新版本的bash里，&>>表示同时追加。不过要注意，&>这种写法在POSIX sh里不支持，如果你要写兼容性很强的脚本，尽量用2>&1的写法。

2.4 输入重定向：< 和 << 与 <<<

输出重定向大家用得熟，输入重定向很多人反而忽略了。

<表示从一个文件读入数据作为命令的标准输入：

bash复制# 把data.txt的内容作为输入喂给wc -l，统计行数
wc -l < data.txt

这等价于cat data.txt | wc -l，但少起了一个进程，更高效。在大量数据处理时，少一个进程的差距可能不明显，但写成管道会额外用到一个cat进程，这在bash的进程管理里是实实在在的开销。而且，<的写法更直观：“从文件里读”，不会产生管道带来的子shell问题。

<<是here-document，用于给命令提供多行文本输入：

bash复制# 把中间的内容作为输入传给cat
cat <<EOF
这是第一行
这是第二行
EOF

这在写脚本时特别有用，比如生成配置文件、构造SQL语句、往文件里写入多行内容：

bash复制cat > nginx.conf <<EOF
server {
    listen 80;
    server_name example.com;
}
EOF

一个cat命令配合here-document，可以直接生成一个多行配置文件，比echo一行一行追加方便多了。注意结尾的EOF必须顶着行首写，后面也不能有空格，否则不会被视为结束标记。很多新手在这个地方报错，就是因为EOF前多了个空格或tab。

<<<是here-string，简单来说就是把一个字符串作为输入fed给命令：

bash复制# 把"hello world"作为输入传给grep，查找hello
grep hello <<< "hello world"

这里注意，<<<后面会自带一个换行符，所以wc -c <<< "abc"得到的是4而不是3。这是很多人用here-string统计字符串长度时发现的诡异现象，其实不是bug，是特性。

3. 管道：让每个命令只做一件事

3.1 匿名管道到底是什么？

重定向是单打独斗，管道是团队协作。

Linux管道的核心思想是：把一个命令的stdout接到另一个命令的stdin，实现数据的流水线处理。形象地说，就像一条传送带，前一个工人加工完，把零件放在传送带上，后一个工人直接拿起来继续加工。

bash复制cat access.log | grep "404" | awk '{print $1}' | sort | uniq -c | sort -rn | head -20

这一条命令，完成了“从日志里找出所有404请求、提取IP、排序、去重计数、再排序、取前20”的完整流程。每个命令只承担一个小任务，而管道把所有任务串成一条高效的流水线。这就是Linux哲学里“让每个程序只做好一件事”的体现，管道是把这个哲学落地的关键机制。

匿名管道在Linux内核里是一个固定大小的环形缓冲区，传统Pipe Buffer大小在较新内核（2.6.35之后）通常是64KB（65536字节）。写入进程如果写满了，会阻塞等待；读取进程如果读空了，也会阻塞等待。这个机制保证了生产者和消费者的速度能自动协调，不会出现内存爆掉的问题。

这里有两点值得注意：

• 管道中的数据是字节流，没有消息边界。也就是说，如果你往管道里写“hello world”，读取方拿到的就是连续的“hello world”，不会自动帮你切分成两个单词。真正切分字段的工作，要交给后续命令（比如awk、cut）来做。
• 管道中的数据是一次性的。数据被读取之后就会被抛弃，你无法在管道里来回读。所以管道只适合单向流水处理，不适合需要重复访问数据的场景。

3.2 管道和重定向的区别，一张表看清

管道和重定向看着有点像，但本质上是两回事。我每次讲课都会用这张表来对比：

管道符|真的是Linux命令组合中最厉害的设计之一。它让原本需要写一个程序才能完成的处理流程，变成了一条简单的shell命令。

3.3 管道中最容易忽略的两个细节

第一个细节：管道命令只在子shell中执行。什么意思？看这个例子：

bash复制echo "hello" | read var
echo $var

在bash中，read var会运行在一个子shell进程中，它读取的变量在子shell里赋值，只要子shell结束，变量就消失了。所以第二行的echo $var输出的是空行。

同样的道理也适用于循环：

bash复制cat file.txt | while read line; do
    count=$((count+1))
done
echo $count

这里的count变量同样是在子shell中修改的，循环结束后，外层shell的count不变。这个问题让很多人写脚本时摸不着头脑。解决方案有几种：使用进程替换（<(command)）、把处理逻辑封装到子shell内部输出、或者干脆把整个管道放在同一层执行。最简单的办法是把循环体放到{ }里：

bash复制cat file.txt | { while read line; do count=$((count+1)); done; echo $count; }

不过更推荐的做法是用<重定向替代管道读文件：while read line; do ...; done < file.txt，这样循环就在当前shell执行，变量能保留下来。

第二个细节：管道会引发SIGPIPE信号。如果你用head -1从一个持续输出的命令那里取数据，管道缓冲区读满后，写端就会收到SIGPIPE而被终止。比如：

bash复制yes | head -1

yes命令本来会无限输出“y”，但因为head -1读完第一行就退出了，管道关闭，yes再写数据时就会收到SIGPIPE信号而终止。这个行为看起来像是yes崩溃了，其实是正常的协同机制。

3.4 管道配合xargs的实际操作

管道传递的是标准输入，但不是所有命令都能从标准输入读取参数。rm、ls、mkdir这些很多命令不接受标准输入传参，管道喂给它们的数据会被忽略。xargs就是用来解决这个问题的：

bash复制# 找出所有.log文件并删除
find /var/log -name "*.log" | xargs rm -f

# 找出所有包含"Nginx"的进程并杀掉
ps aux | grep Nginx | grep -v grep | awk '{print $2}' | xargs kill -9

这里有个小技巧：grep -v grep是为了把grep自身进程过滤掉，防止误杀。而awk '{print $2}'是从ps输出中提取PID列。

用xargs时注意几个参数：

• -n 1：每次只传一个参数给命令，适合处理单个文件的操作。
• -I {}：指定参数占位符，可以用在参数嵌入中间的场景：find . -name "*.txt" | xargs -I {} cp {} /backup/
• -0：配合-print0使用，处理文件名包含空格、换行等情况。
• -P：指定并行数，能显著加快处理速度，但要注意目标系统是否能承受并发压力。

文件名里带空格是个经典坑：find . -name "*.txt" | xargs rm如果遇到文件名带空格，会被xargs拆成两个参数，导致误删或报错。正确做法是：find . -name "*.txt" -print0 | xargs -0 rm。

4. tee：管道里的分流闸门

4.1 tee的基本用法：一鱼两吃

tee的作用一句话概括：把标准输入同时写到标准输出和一个或多个文件中。就像水管工装了一个三通接头，水流经过的时候，既能继续流向后面，又能分出一股存在水箱里。

看语法：

bash复制command | tee [OPTION]... [FILE]...

最经典的场景：

bash复制# 一边执行编译，一边把完整输出保存下来
make | tee build.log

没有tee的时候，你要么运行make > build.log，这样屏幕上什么都没有，编译到哪一步了全靠猜；要么让输出直接打在屏幕上，但事后想翻记录又没了。有了tee，两边兼顾，屏幕上实时看到进度，build.log里也留了完整备份。

在定位问题时这个功能尤其好用。有时候一个错误信息刷过去，你根本没看清，如果当时是make | tee build.log，那事后直接grep -i error build.log就能找到问题所在。

4.2 tee的常用参数：-a追加和其他选项

• -a或--append：追加到文件而不是覆盖。这个参数救了我很多次，尤其是长时间的日志采集场景。
• -i或--ignore-interrupts：忽略中断信号，在交互式环境里跑长任务时，能避免误按Ctrl+C导致数据丢失。

bash复制# 把新数据追加到运行日志里，而不是覆盖
echo "=== `date` 开始部署 ===" | tee -a deploy.log
./deploy.sh 2>&1 | tee -a deploy.log
echo "=== `date` 部署结束 ===" | tee -a deploy.log

这个模式写部署脚本时非常实用。整个部署过程的日志会完整记录在deploy.log里，屏幕上也能实时看到进度，出了问题直接翻日志。

还有个冷门参数-p，在较新版本的GNU coreutils里支持，用于诊断写文件时的错误。不过我日常用得很少，一般只有在写关键审计日志的脚本里才会用到。

4.3 tee与sudo配合：绕过权限限制

tee在运维中还有个神级用法：配合sudo写受保护的文件。

如果你用普通用户执行：

bash复制echo "127.0.0.1 mydomain.com" > /etc/hosts

会得到Permission denied。你可能会想，那就加sudo呗：

bash复制sudo echo "127.0.0.1 mydomain.com" > /etc/hosts

结果依然报Permission denied。为什么？因为sudo echo只是让echo命令以root运行，但重定向> /etc/hosts是由当前shell执行的，shell的权限还是普通用户，所以打开/etc/hosts这个文件时依然被拒绝。

正确姿势是用tee：

bash复制echo "127.0.0.1 mydomain.com" | sudo tee -a /etc/hosts

这里的逻辑是：echo以普通用户运行，输出字符串到管道；sudo tee以root权限运行，把管道里的数据追加到/etc/hosts。因为tee是root启动的，所以它打开/etc/hosts时就有权限了。

如果你不想让内容重复显示在屏幕上，可以把tee的标准输出重定向到/dev/null：

bash复制echo "127.0.0.1 mydomain.com" | sudo tee -a /etc/hosts > /dev/null

这个组合拳在改系统配置文件时是常规操作，凡是遇到“命令加了sudo还写不进去”的诡异问题，先想想是不是重定向没在sudo的管辖范围内。

4.4 用tee把脚本输出分文件保存

还有一个让很多人眼前一亮的用法：在一个脚本里，把不同类型的日志分别存到不同文件，同时屏幕照常显示。

比如你有一个部署脚本，想把标准输出和标准错误分别存档：

bash复制{
    echo "开始部署"
    ./build.sh
    echo "部署完成"
} > >(tee -a stdout.log) 2> >(tee -a stderr.log >&2)

这个写法用了进程替换>()，稍显复杂，但效果非常好：正常日志进stdout.log，错误日志进stderr.log，同时屏幕上都能看到实时输出。这在审计和排障时的信息量是完全不同的。

不过我要提醒的是，进程替换里的tee会异步执行，脚本结束时，teed进程可能还没写完缓冲区的数据就退出了。稳妥做法是在脚本末尾加一句sync，或者用wait等待子进程结束。

5. 组合拳：日常运维中的管道、重定向、tee搭配

5.1 日志轮转与备份的实用组合

实际运维中，单纯用某一个命令的场景其实不多，更多的是组合使用。比如你要给一个应用做日志归档：

bash复制# 把当前日志压缩备份，同时记录时间戳
tar czf logs_$(date +%Y%m%d_%H%M%S).tar.gz /var/log/myapp/ | tee backup_summary.txt

# 压缩过程中统计文件数量
tar tzf logs_*.tar.gz | wc -l | tee file_count.txt

又比如你要对一批服务器批量执行命令，把结果汇总：

bash复制for host in server1 server2 server3; do
    echo "=== $host ===" | tee -a all_results.log
    ssh "$host" "uptime && free -m" 2>&1 | tee -a all_results.log
done

这段脚本会逐个连服务器，把每台服务器的状态汇总到一个日志文件里，同时屏幕上也能看到。在线排查多机问题时，这个模式既实时又留痕。

5.2 用管道统计日志中的有效数据

日志分析是管道用得最密集的领域。假设你要分析nginx访问日志里各个URL的访问量：

bash复制cat access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head -10

拆解一下每一环节：

• cat 读出日志内容。
• awk '{print $7}' 取出第七列，nginx默认日志格式里第七列是请求的URL路径。
• sort 排序，让相同URL排在一起。
• uniq -c 统计每行出现的次数。
• sort -rn 按次数从大到小排序。
• head -10 取前10条。

这里面很容易犯的一个错是忘记sort直接uniq -c，导致统计结果不对。因为uniq只处理相邻的重复行，如果相同URL在文件里不是连续出现，它就会当成两个不同的值来统计。所以先sort后uniq是固定的顺序约定。

5.3 结合tee做数据存档与二次分析

有一次我写了一个数据处理脚本，要从一个大文件里提取某些字段，同时统计整体情况。我用了tee把提取后的数据完整存档，然后管道继续做统计：

bash复制cat raw_data.txt | awk -F',' '{print $1,$3,$5}' | tee extracted.csv | awk '{sum+=$2} END {print "平均值:", sum/NR}'

这样extracted.csv里保存了提取后的完整数据，屏幕输出的是统计结果。之后如果老板问“你那个平均值是怎么算的？”或者“你能把每条数据都列出来吗？”我直接打开extracted.csv就行，不用重新跑一遍脚本。

这种做法的好处在于：“存档”和“实时分析”互不干扰，原始数据和处理后数据都有留存，审计时清清楚楚，也不怕误删。

5.4 小心使用sudo和高权限重定向

很多新手容易在这里翻车。我之前遇到过一位同事，想往/etc/sysctl.conf里追加配置，他写道：

bash复制echo "vm.swappiness=10" >> /etc/sysctl.conf

普通用户执行直接Permission denied，这个还好，至少没造成破坏。但更危险的是另一种：你本来是普通用户，某个脚本用sudo执行了，脚本内部有重定向，但重定向是在子shell中执行的，最终因为权限不够，反而没有生效。这时候你根本不知道配置没写进去，等到重启才傻眼。

这类问题的排查思路很简单：看文件的时间戳和实际内容，或者执行后立即用tail -5验证一下。

对于这类需要高权限写文件的场景，我的一贯做法是：

bash复制# 先将内容写到普通文件，再sudo移动过去
echo "vm.swappiness=10" > /tmp/sysctl_tmp
sudo mv /tmp/sysctl_tmp /etc/sysctl.conf

或者干脆用上一节讲的sudo tee方案：

bash复制echo "vm.swappiness=10" | sudo tee /etc/sysctl.conf > /dev/null

这样至少能确保写入动作是用root权限执行的，减少“以为写了其实没写”的隐患。

6. 常见问题与排查技巧实录

6.1 问题速查表

下面是我这些年开发、运维中遇到的与重定向、管道、tee相关的高频问题，汇总成一张速查表：

这张表我建议直接收藏，遇到问题先对照一下，比自己瞎试快得多。

6.2 排错方法论

排错时我总是遵循“最小化验证”原则：每次只改动一个环节，然后在关键节点用echo或tee打印中间状态。比如：

bash复制cat access.log | awk '{print $7}' | tee /tmp/url_only.log | sort | uniq -c | sort -rn | head -10

如果统计结果不符合预期，先去/tmp/url_only.log看提取出的URL格式对不对。如果这一步的数据就乱了，那后面所有环节的结果都不可能正确。

另一个常用的调试技巧是在管道中间插入head或cat -A来检查数据内容的真实格式：

bash复制cat access.log | calf | awk '{print $7}' | head -3

cat -A能显示出行尾的$符号和特殊字符，方便排查隐藏的空格、制表符等问题。管道处理文本出问题时，80%以上是数据格式不符预期，而不是逻辑错误。

6.3 tee的缓存与性能经验

当你用tee写超大日志时，可能会遇到一个现象：屏幕上已经在跑下一个任务了，但日志文件还停在旧位置。这是因为tee底层的stdio库有缓冲机制，写入内容先进入缓冲区，到一定量或脚本退出时才flush到磁盘。

理论上，只要tee进程正常退出，缓冲区最终会落盘。但如果脚本被强杀或系统突然断电，缓冲数据就丢了。关键日志场景，建议在tee命令前用stdbuf -oL强制行缓冲：

bash复制your_command | stdbuf -oL tee -a critical.log

stdbuf -oL的作用是让命令的输出以行缓冲模式运行，每输出一行就立即刷新一次缓冲区。对实时性要求高的场景帮助很大，代价是性能略有下降。但对于大多数日志场景来说，这个性价比很高。

还有一个性能相关的点：当你用tee同时写多个文件时，它会把数据逐份写入每个文件，磁盘IO会成倍增加。比如一条命令tee到三个文件，日志写入量就变成了三倍。在磁盘压力大的服务器上，尽量控制tee的文件数量，或者改用硬链接/符号链接指向同一份日志，减少实际写入。

6.4 一个真实的生产事故复盘

最后分享一个我实际经历过的案例，很有代表性。

有一次我们上线一个新服务，启动脚本里有一句：

bash复制nohup ./my_server >> /var/log/my_server.log 2>&1 &

看起来没问题是吧？nohup保证进程不被SIGHUP信号干掉，>>追加，2>&1合并错误输出，&放后台。但奇怪的是，服务跑着跑着，日志文件越来越大，最后把磁盘塞满了。

排查过程：

• 第一步，看日志大小：ls -lh /var/log/my_server.log，已经是30GB了。
• 第二步，看日志内容：tail -100 /var/log/my_server.log，发现里面大量重复的报错刷屏。
• 第三步，看是什么在写：lsof | grep my_server.log，发现除了主进程，还有一个子进程也在写同一个文件。

问题就出在我当时写日志的方式上：主进程自己会写日志，同时它又fork了一个子进程，子进程的stdout也被我重定向到了同一个日志文件。两个进程同时写同一个文件，没有行锁，日志内容交织在一起，而且某些高并发情况下写入速度非常快，磁盘瞬间就被撑爆了。

最终的修复方案：改成让主进程统一收集日志，子进程的stdout重定向到主进程的管道，再由主进程决定写到哪个文件。这样日志写入就只有一个出口，不会并发写同一个文件。

这里想借这个案例说明一个观点：重定向、管道、tee这些工具单独看都很简单，但组合在实践中时，牵涉进程模型、文件描述符继承、缓冲机制、并发写入等多个层面的问题。新手容易只关注“命令怎么写”，老手则会关注“整个进程组的文件描述符是怎么流转的”。

7. 关于凡人修云这个系列，说点题外话

前面几篇都在讲单点知识，这一篇把这些点串成了线。重定向、管道、tee三者本质上是一套思想的三个侧面：控制数据流向、串联处理步骤、分流保存数据。在Linux世界里，“一切皆文件”加上“数据流可导向任何地方”这两个基本思想，支撑起了整个shell生态的灵活性。

往后真的遇到复杂场景时，建议不要急着去查命令，先画出数据流图：数据从哪里来，经过哪些处理，最终落到哪里，哪些地方需要分流存档。图一画出来，该用什么命令、怎么组合，答案往往自己就浮出水面了。

有时候解决问题不一定靠多高深的命令，而是靠对数据流动方向的理解足够清晰。这是我这些年踩过无数坑之后的最大体会。希望这篇文章能帮你少走几步弯路。