`cat file|cmd`与`cmd < file`是否等效？何时需用STDIN重定向？

嘿，这俩问题问到点子上了，刚好是不少shell新手容易搞混的细节，我来给你掰扯清楚：

1. cat foo.txt | my_cmd 和 my_cmd < foo.txt 效果一致吗？ #

大部分日常场景下，这俩命令的实际输出效果是完全相同的——都是把foo.txt里的内容喂给my_cmd当标准输入（STDIN）。但背后的实现逻辑其实有区别：

• my_cmd < foo.txt是让shell直接把foo.txt绑定到my_cmd的STDIN上，全程只启动一个my_cmd进程，是更直接的方式。
• cat foo.txt | my_cmd会启动两个进程：cat负责读文件并把内容吐到管道里，my_cmd再从管道里读输入。

不过有个极端情况会导致效果不一样：如果my_cmd会检查自己的STDIN是不是真实的本地文件（比如有些工具要做文件定位lseek，或者获取文件大小这类操作），那my_cmd < foo.txt能正常工作，但cat ... | my_cmd就会报错——因为管道是流式的，不支持随机访问这类文件操作。

2. 哪些场景必须用STDIN重定向？有没有必要用cat管道传输入？ #

必须用<重定向的场景： #

• 命令需要随机访问输入内容：比如less查看大文件时要跳转页、某些数据库导入工具要校验文件大小，这些操作都依赖文件的可定位特性，管道做不到，只能用<直接绑定真实文件。
• 追求极致效率的场景：虽然单个cat进程的开销微乎其微，但如果是在循环里反复执行（比如脚本里遍历上百个文件），累计的进程开销就会显现，用<更高效。
• 处理特殊设备文件：比如访问/dev/urandom或者串口设备/dev/ttyS0时，直接用< /dev/urandom能更好地适配设备的流式特性，cat中间插一脚可能会引入不必要的缓冲问题。

什么时候cat管道反而更实用？ #

虽然cat管道常被老炮儿吐槽为“无用cat（useless use of cat）”，但也有合理的使用场景：

• 合并多个文件输入：比如cat file1.txt file2.txt | my_cmd，能一次性把多个文件的内容拼接后传给my_cmd，用重定向的话得写my_cmd < <(cat file1.txt file2.txt)或者临时文件，反而麻烦。
• 直观的链式预处理：比如cat foo.txt | grep -v "^#" | my_cmd，先过滤掉注释行再传给主命令，这种写法比嵌套子shell的重定向更易读，新手也能一眼看懂逻辑。
• 兼容老旧shell：有些非常老的shell（比如早期的Bourne Shell）不支持进程替换<(...)，这时候cat管道是合并多文件输入的唯一简洁方式。

内容的提问来源于stack exchange，提问作者Chap