为何‘exec 7<>$tmp_file’能让命名管道写入非阻塞？

问题背景 #

我是bash脚本编程新手，正在理解以下两段代码：

第一段代码（写入会阻塞） #

tmp_file=/tmp/tmp_file$$
mkfifo $tmp_file
echo "msg_A" >$tmp_file # 会阻塞，因为管道无缓冲且无读取端
read msg <$tmp_file
echo $msg

第二段代码（写入不再阻塞） #

tmp_file=/tmp/tmp_file$$
mkfifo $tmp_file

exec 7<>$tmp_file # 添加此行

echo "msg_A" >$tmp_file # 现在写入操作不再阻塞，原因是什么？
read msg <$tmp_file
echo $msg  # 输出msg_A

我想了解上述代码中exec 7<>$tmp_file的作用，以及为何添加该行后写入操作变为非阻塞？

解答 #

exec 7<>$tmp_file的具体作用 #

这条命令是让bash进程用自定义文件描述符7，以双向读写模式打开指定的FIFO管道：

• <>是bash的特殊语法，表示同时打开文件的读和写权限
• 数字7是未被系统默认占用的文件描述符（系统默认用0、1、2分别表示标准输入、标准输出、标准错误）
• 执行后，bash会持续保持这个FIFO的读端和写端处于打开状态，除非你用exec 7>&-显式关闭这个描述符

写入操作不再阻塞的原因 #

FIFO管道的核心规则是：必须同时存在打开的读端和写端，读写操作才能正常进行，否则会阻塞。

• 第一段代码里，执行echo "msg_A" >$tmp_file时，只打开了FIFO的写端，但此时没有任何进程打开读端，bash会强制阻塞这个写入操作，等待读端被打开。但问题是，阻塞的写入会卡住脚本，后面的read命令根本没机会执行，最终脚本彻底停住。
• 第二段代码中，exec 7<>$tmp_file提前打开了FIFO的读端和写端，相当于给管道“留了口子”。此时再执行写入操作时，管道的读端已经处于打开状态，满足了FIFO的运行条件，写入就能立即完成，不会阻塞，后续的read也能顺利读到内容。

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