SSH脚本双向通信配置故障排查：命名管道方案为何失效？

一、命名管道方案失效的常见原因 #

• 管道初始化时机不匹配：ksh98和bash对命名管道的打开逻辑有差异——如果某一端先创建管道并尝试写入，但另一端还没打开管道读取，写入进程会直接阻塞挂起。比如你可能在SSH连接建立前就创建了管道，但没确保QNX端的ksh98进程已经关联到管道，导致发送端卡住。
• SSH终端重定向冲突：SSH默认会绑定终端的stdin/stdout，如果你手动将其重定向到命名管道，容易和-t（强制分配终端）或-T（禁用终端）参数冲突。比如加了-t会让管道IO被终端设备干扰，不加-T的话ksh98某些命令可能因无终端而异常，最终导致通信中断。
• 管道EOF处理遗漏：ksh98中，当管道写入端关闭时，读取端会收到EOF，但如果脚本没处理这个状态，会一直等待输入挂起。比如SSH会话结束后，本地或远端的进程没正确关闭管道句柄，残留进程持有管道，导致另一端无法退出。
• 权限模型不兼容：如果Windows用的是WSL bash，创建的命名管道权限和Linux/ksh98的权限模型不匹配，导致远端无法读写管道，进而触发阻塞。

二、无需命名管道的实现方式 #

1. 原生SSH双向IO（最简洁） #

直接利用SSH本身的stdin/stdout绑定，不需要额外管道。脚本化示例：

# Windows bash端脚本
ssh user@qnx-host 'ksh -s' << 'EOF'
# QNX端ksh98处理逻辑
while read input_line; do
    echo "[QNX] 收到: $input_line"
    # 执行命令并返回结果，比如获取系统时间
    echo "[QNX] 当前时间: $(date)"
    # 收到exit就退出循环
    [[ "$input_line" == "exit" ]] && break
done
EOF

如果需要动态发送数据，用管道配合：

# bash端动态发送指令并接收返回
(echo "查看进程"; sleep 1; echo "exit") | ssh user@qnx-host 'ksh -s' << 'EOF'
while read cmd; do
    [[ "$cmd" == "exit" ]] && break
    echo "[QNX] 执行命令: $cmd"
    # 执行命令并返回输出
    eval "$cmd"
done
EOF

2. coproc 进程协作（适配ksh98差异） #

虽然你已经了解coproc，但要注意ksh98的语法细节。bash端用coproc管理SSH会话，ksh98端处理输入：

# bash端启动coproc关联SSH
coproc SSH_SESSION=ssh user@qnx-host 'ksh -s'
# 发送指令到QNX
echo "获取磁盘使用情况" >&${SSH_SESSION[1]}
# 读取返回结果
read -r response <&${SSH_SESSION[0]}
echo "[Bash] 收到: $response"
# 关闭会话
echo "exit" >&${SSH_SESSION[1]}
wait $SSH_SESSION_PID

QNX端ksh98的处理脚本（也可以写在SSH命令里）：

# ksh98端逻辑
while read request; do
    [[ "$request" == "exit" ]] && break
    df -h
done

3. 进程替换实现双向分流 #

用bash的进程替换，将本地输出作为SSH的stdin，同时把SSH的stdout定向到本地处理进程：

ssh user@qnx-host 'ksh -s' < <(
    # 本地发送的指令序列
    echo "uptime"
    sleep 1
    echo "whoami"
    echo "exit"
) > >(
    # 本地处理远端返回的逻辑
    while read output; do
        echo "[Bash 接收] $output"
    done
)

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