为何Java调用Process执行rar解压命令时getInputStream返回结果与命令行不一致？

执行RAR解压命令rar x file_to_extact.rar /tmp/some_dir时，存在两种不一致的输出表现：

• 直接在交互式命令行执行该命令时，程序会正常输出版本版权信息，遇到带密码的加密压缩包时，会主动显示Enter password...的交互提示，流程输出完整正常。
• 通过Java代码的ProcessBuilder启动该命令时，通过getInputStream()、getErrorStream()获取到的输出与命令行结果大体一致，但始终缺失Enter password...的密码提示内容。
• 已知可通过RAR自带的-p参数检测压缩包是否设置密码，但无法解释相同命令在两种执行场景下的输出差异。

差异本质来自命令行程序对运行环境的交互性检测逻辑：

• 所有带交互能力的命令行工具（包括RAR）启动时，都会检测自身的标准输入是否连接到真正的交互式TTY（即用户日常使用的命令行终端窗口）。
• 直接在命令行执行时，RAR的输入、输出通道都直连终端设备，会触发完整的交互逻辑，正常输出密码提示等待用户输入。
• Java通过ProcessBuilder启动子进程时，默认会通过操作系统管道（Pipe）连接子进程的输入、输出、错误流。此时RAR检测到自身输入并非交互式终端，会自动切换到非交互执行模式，跳过所有面向终端的交互提示输出，最终出现缺失密码提示的现象。
• 现有示例代码中串行读取输入流、错误流的逻辑也存在潜在阻塞风险：代码先读完输入流再读取错误流，当子进程向错误流写入的内容超过操作系统管道缓冲区默认大小（通常4KB-8KB）时，子进程会因缓冲区写满阻塞，导致整个流程卡死。

要获取与命令行执行完全一致的输出，核心是让RAR进程感知到自身运行在交互式终端环境中，常见实现方式：

1. 系统工具模拟伪终端（PTY）
   在Linux、macOS环境下，可使用系统自带的script命令包裹原有RAR命令，强制为子进程分配伪终端设备。修改后的Java启动代码示例：

   Process process = new ProcessBuilder(new String[] {
       "script", "-q", "/dev/null", "rar", "x", "file_to_extact.rar", "/tmp/some_dir"
   }).start();
   

   该方式无需引入第三方依赖，RAR检测到伪终端环境后，会正常输出所有交互提示内容。
2. Java生态PTY库模拟终端
   如需跨平台兼容（如Windows环境），可使用pty4j这类为Java设计的伪终端模拟库，手动创建PTY设备后启动RAR进程，将子进程的输入输出绑定到PTY设备上，即可拿到与终端执行完全一致的输出。
3. 修正流读取逻辑

   无论采用哪种终端模拟方式，都需要将输入流、错误流的读取逻辑并行化：单独启动独立线程分别监听两个流的输出，避免管道缓冲区写满导致的子进程阻塞。

内容的提问来源于stack exchange，提问作者Bestows In Constructing