linux重定向是shell启动时对文件描述符的底层接管，非语法糖；执行顺序决定重定向结果，如> file 2>&1与2>&1 > file行为不同，因shell从左到右解析并绑定文件描述符。
Linux 重定向不是“语法糖”，而是 shell 进程启动时对文件描述符（stdin、stdout、stderr）的底层接管，理解这点才能避开绝大多数误用。
为什么 command > file 2>&1 和 command 2>&1 > file 结果不同
执行顺序决定文件描述符绑定时机。shell 从左到右解析重定向，2>&1 是把 stderr 指向当前的 stdout 目标，而 > file 会覆盖 stdout 的目标。
-
command > file 2>&1：先将stdout重定向到file，再让stderr指向此时的stdout（即file）→ 两者都写入file -
command 2>&1 > file：先让stderr指向原始stdout（通常是终端），再把stdout改为file→stderr仍输出到终端，stdout写入file
验证方式：ls /nonexist /tmp 2>&1 > out.txt 会在终端打印错误，out.txt 只含 /tmp 列表；反之则全部进文件。
2>/dev/null 看似静音，但可能掩盖关键问题
/dev/null 是黑洞设备，写入即丢弃，但它的存在不改变进程退出状态。很多脚本错误地认为“没输出=成功”，其实 grep 找不到内容时返回非零退出码，command 2>/dev/null 后直接跟 && echo ok 仍可能跳过。
- 真正需要静音且忽略失败：用
command 2>/dev/null || true - 只想屏蔽错误但保留失败语义：别重定向
stderr，改用command 2>/dev/null+ 显式检查$? - 注意权限问题：
command > /root/log.txt 2>/dev/null若当前用户无权写入/root，重定向本身会失败，命令根本不会执行
用 exec 实现整个 shell 会话级重定向
exec 不启动新进程，而是替换当前 shell 的文件描述符，适合批量捕获或日志归档场景。
-
exec > all.log 2>&1：此后所有命令的stdout和stderr都写入all.log（包括后续echo、ls等） - 恢复默认输出：
exec > /dev/tty 2>/dev/tty（假设你还在终端） - 注意：一旦执行
exec > file，原stdout就不可逆——除非提前用exec 3>&1保存副本，之后用exec 1>&3恢复
常见误用：exec 2>&1 | tee error.log 是错的，因为 | 创建子 shell，exec 的重定向在子 shell 中失效。
管道和重定向混用时，stderr 默认不进管道
管道只传递 stdout，stderr 仍直连终端。这常导致 grep 看不到错误，或 head -n1 截断后还看到报错信息。
- 让
stderr也进管道：command 2>&1 | grep "pattern" - 只过滤
stdout，保留stderr显示：command 2>&1 | grep "pattern" 1>&2（把管道输出再重定向回stderr） - 分离记录：
command > out.log 2> err.log比command &> all.log更利于排查，尤其当错误信息带时间戳或上下文时
真实痛点：某些命令（如 rsync）的进度条走 stderr，若你用 rsync ... | grep 却没加 2>&1，就完全看不到进度——它根本没进管道。
