Rust开发插件系统时如何在不干扰用户stdin的前提下与子进程通信

方案1：拆分通信通道与终端交互通道（最推荐） #

完全规避标准流复用冲突，不需要做任何输入中转，符合你不希望增加复杂度的需求：

• 额外创建一对独立的双向通信通道给主程序和插件做控制信令交互，插件的stdin/stdout/stderr直接继承主程序的终端句柄，不做劫持
• 轻量实现可选匿名管道或者Unix域套接字对，Rust下可以直接用std::os::unix::net::UnixStream::pair()创建双向流，子进程启动时通过环境变量或者继承文件描述符的方式把通信端传给插件
• 插件侧约定好：控制指令只走独立通信通道，和用户交互的输入输出直接走标准输入输出，完全不会和主程序的控制逻辑冲突

示例代码片段：

use std::os::unix::io::AsRawFd;
use std::os::unix::net::UnixStream;
use std::process::{Command, Stdio};
use std::io::{BufRead, BufReader, Write};

// 创建双向通信流
let (main_stream, plugin_stream) = UnixStream::pair().unwrap();

// 子进程直接继承终端的stdin/stdout/stderr，把通信流作为额外fd传递
let mut child = Command::new("test.pl")
    .stdin(Stdio::inherit())
    .stdout(Stdio::inherit())
    .stderr(Stdio::inherit())
    .env("PLUGIN_COMM_FD", "3") // 告诉插件通信用的fd编号
    .pre_exec(move || {
        // 把plugin_stream移动到fd3的位置，避免被其他fd占用
        let plugin_fd = plugin_stream.as_raw_fd();
        if plugin_fd != 3 {
            unsafe { libc::dup2(plugin_fd, 3) };
            unsafe { libc::close(plugin_fd) };
        }
        Ok(())
    })
    .spawn()
    .expect("Failed to spawn child process");

// 主程序单独开线程处理控制通信，不阻塞终端交互
std::thread::spawn(move || {
    let mut reader = BufReader::new(&main_stream);
    let mut writer = &main_stream;
    let mut line = String::new();
    while reader.read_line(&mut line).unwrap() > 0 {
        match line.trim() {
            "member_list" => {
                let mlist = cluster::members_list().unwrap();
                for (member, port) in mlist.iter() {
                    writeln!(writer, "{}:{}", member, port).unwrap();
                }
            }
            _ => {}
        }
        line.clear();
    }
});

child.wait().unwrap();

方案2：标准流复用+标记帧 #

如果必须使用标准流做通信，可以通过约定特殊标记区分控制指令和普通交互内容，不需要丢弃stdin句柄：

• 插件输出的控制指令用唯一前后缀包裹，比如%%CMD:member_list%%，其余普通输出直接透传给用户
• 主程序在读取子进程stdout时，判断内容是否为控制指令：是则走内部逻辑响应，写入子进程stdin；否则直接打印到终端
• 当插件需要用户输入时，主程序直接读取当前终端的标准输入，写入子进程stdin即可，逻辑统一不需要额外拆分

方案3：Unix域套接字监听（跨进程兼容性更好） #

如果插件可能用不同语言开发，主程序可以启动时监听一个临时Unix域套接字路径，通过环境变量传给插件：

• 比HTTP、DBus轻量非常多，没有额外依赖，支持全双工通信
• 完全不占用标准流，插件的终端交互完全不受主程序影响
• Windows下可以替换为命名管道，逻辑基本一致

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