你遇到的这个现象其实是Shell解析命令的优先级和管道机制共同作用的结果，我来一步步给你拆解：

1. Shell先处理重定向，再执行命令 #

Shell在执行任何命令之前，会先解析并处理所有重定向操作。在你的命令echo hello | > ./out里，管道|和重定向>的处理顺序是关键：

• 首先，Shell会创建一个包含读端、写端的管道。
• 接着处理> ./out：这个重定向会截断（若文件已存在）或创建./out文件，并把管道右侧子shell的标准输出指向这个文件。
• 但管道右侧没有任何实际命令——相当于启动了一个空的子shell，它只完成了打开./out的操作，随后就直接退出了。

2. 管道读端提前关闭，导致echo输出丢失 #

左边的echo hello会尝试把字符串"hello"写入管道的写端，但此时管道的读端已经因为右侧空子shell的退出而被关闭。按照Unix管道的规则：

• 当进程尝试往读端已关闭的管道写数据时，系统会给该进程发送SIGPIPE信号，默认行为是终止进程。
• 但大多数Shell默认不会主动报告这个信号导致的退出（除非你设置set -o pipefail选项），所以你看不到任何错误提示。
• 而echo的输出因为没有被任何进程读取，自然也不会写入./out，最终文件就是空的。

3. 为什么你预期的错误没出现？ #

你可能以为管道右侧必须有明确的命令，但Shell其实允许管道连接到“空命令”（即什么都不执行的子shell）。这种情况下重定向依然会被正常处理，不会触发语法错误——因为从Shell的语法规则来看，> ./out是合法的重定向操作，哪怕它前面没有显式命令。

如果想让echo的输出写入./out，直接写echo hello > ./out就可以（不需要管道）；如果一定要用管道，也可以写成echo hello | cat > ./out，让cat读取管道内容并写入文件。

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