如何让Bash管道中的交互read读取终端stdin而非管道数据

首先明确你之前尝试的read <&0、read -u /dev/stdin写法失效的核心原因：
在sort -R words.list | while ...的传统管道结构中，while循环会运行在独立的子shell中，这个子shell的标准输入（fd0）已经被重定向为管道的读端。所有指向fd0的读取操作、以及指向/dev/stdin的读取，本质上都是从管道流里拿数据，根本关联不到真实的终端，自然没法实现等待用户按键的效果。

方案1：直接从控制终端读取（最适配你的需求） #

绕开被管道占用的标准输入，直接让等待按键的read命令读取进程关联的控制终端设备/dev/tty，这是最直接匹配你“为第二个read指定终端输入源”思路的写法：

sort -R words.list | while read p; do
  speak "$p"
  read -r _ < /dev/tty
done

这里的/dev/tty是每个进程专属的控制终端入口，不受管道重定向的标准输入影响。不管当前进程的stdin被改成什么流，读这个路径拿到的永远是和用户交互的终端输入，按下回车就会继续执行后续逻辑。代码里的_是bash约定的无意义占位变量，因为我们只需要等待用户输入回车的信号，不需要留存实际输入的内容，用这个占位符可以避免无关shell变量被read意外覆盖。

方案2：保存终端文件描述符，配合进程替换运行循环 #

如果你不想在循环里硬写/dev/tty，可以提前把真实终端的文件描述符保存下来，再用进程替换替代传统管道，避免循环被丢到子shell、stdin被管道占用：

# 提前把终端输入绑定到fd3，作为交互输入的固定来源
exec 3< /dev/tty
# 用进程替换给while循环提供逐行读取的内容，不影响原有shell的stdin
while read p; do
  speak "$p"
  # 交互等待的read指定从保存的fd3读取，也就是终端
  read -u 3 _
done < <(sort -R words.list)

这种写法的优势是可以灵活控制哪些读取操作用管道流的内容，哪些用来和用户交互，不会出现输入流混淆的问题。

方案3：预加载内容到数组，完全绕开管道输入占用 #

如果words.list的体积不大，可以先用mapfile把排序后的内容一次性读到shell数组里，后续遍历数组的过程完全没有管道重定向的干扰，裸的read命令就能正常从终端读取：

# 把排序后的逐行内容读到lines数组中
mapfile -t lines < <(sort -R words.list)
for p in "${lines[@]}"; do
  speak "$p"
  # 没有任何重定向占用stdin，read直接等待用户回车即可
  read _
done

核心逻辑提醒：不管用哪种方案，本质都是要把两类读取流做隔离——管道流用来逐行读取待处理的内容，交互等待的read必须绑定到不受管道流影响的终端输入源，否则就会出现read提前读完管道内容直接退出、根本等不到用户按键的问题。

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