既然管道已存在，为何Shell还要实现多种stdin重定向方式？

既然管道（|）已经存在，为何Shell还要实现诸如<<<、< <(command)以及< /dev/fd/*这类替代方式来将内容重定向至stdin？

使用|的方式（经典管道） #

echo 'text' | sed 's/x/y/'
# 或
cat - | sed 's/x/y/' # 之后输入文本

使用<<<的方式 #

sed 's/x/y/' <<< 'text'

使用< <(command)的方式 #

sed 's/x/y/' < <(echo 'text')
# 其中<(command)会变为类似如下的文件描述符
sed 's/x/y/' < /dev/fd/42

以上所有方式的输出均为teyt。

这些替代方式并非多余，它们各自解决了经典管道无法覆盖的场景，核心优势如下：

1. <<<（Here String）：简洁高效的字符串输入 #

• 无额外进程开销：经典管道需要启动echo这类辅助进程生成字符串，而<<<直接由Shell把字符串传入目标命令的stdin，避免了进程创建的性能损耗，尤其适合频繁调用的简单场景。
• 语法更直观：直接把目标字符串写在命令后方，不用拆分前后两个命令，可读性更强，比如sed 's/x/y/' <<< 'text'比echo 'text' | sed 's/x/y/'更紧凑。
• 特殊字符处理更简单：对于包含空格、引号或转义字符的字符串，直接用单/双引号包裹即可，无需复杂转义，比如grep 'hello' <<< "I said 'hello world'"能直接正确匹配。

2. < <(command)（进程替换）：多输入源与参数兼容 #

• 支持多文件输入：很多命令需要接收多个文件路径作为参数（比如diff、comm），经典管道只能传递单个数据流，无法满足这类需求。而进程替换可以把命令的输出伪装成临时文件路径，比如diff <(sort file1) <(sort file2)，能直接对比两个命令的输出结果。
• 保留命令参数逻辑：有些命令的核心逻辑依赖命令行参数而非stdin，比如grep pattern file模式。如果用管道，stdin会被占用，无法同时传递文件和数据流；进程替换则可以把命令输出当作文件参数传入，比如grep 'error' <(tail -n 100 log.txt) access.log，同时处理临时数据流和真实文件。
• 多数据流并行处理：可以在同一个命令中同时引入多个不同命令的输出，这是线性的管道无法实现的，比如paste <(cut -d, -f1 data.csv) <(cut -d, -f3 data.csv)，能把同一文件的不同列合并输出。

3. < /dev/fd/*：底层文件描述符控制 #

• 精细的数据流管理：这是进程替换的底层实现方式，直接操作系统的文件描述符，适合复杂脚本中需要手动管理多个输入输出流的场景，比如在脚本中打开多个文件描述符并复用，避免重复创建管道或进程。
• 兼容低版本环境：部分老版本Shell可能不支持进程替换语法，但支持直接访问/dev/fd/*，这种方式能提供更通用的底层控制能力。

简单来说，经典管道是单数据流的线性传递工具，而这些替代方式分别解决了字符串输入效率、多输入源兼容、底层流控制等不同场景的需求，让Shell脚本的编写更灵活高效。

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