ProcessBuilder与Runtime.exec对Bash/Sh的依赖机制及Docker脚本报错排查

ProcessBuilder与Runtime.exec对Shell解释器的依赖本质 #

• 两个类的底层实现均直接对接操作系统的exec系统调用，不会自动隐式查找、调用系统Shell，所有执行逻辑完全由你传入的命令数组决定。
• 命令数组的第一个元素会被当作要加载运行的可执行程序，后续所有元素都是这个可执行程序的传入参数：
  • 如果你显式把bash、/bin/sh这类解释器放在数组第一个位置，才会启动对应Shell来执行后续的脚本或命令；
  • 如果你直接把脚本路径放在数组第一个位置，系统会根据脚本头部的Shebang声明（比如#!/bin/bash）查找对应解释器执行，和Java代码里传什么Shell没有关系。
• 两者本身没有对Bash/Sh的硬编码依赖，所谓的“依赖”完全来自你传入的参数逻辑和目标机器上预装的解释器环境。

Docker环境执行失败的对应原因（匹配你的测试结果） #

你遇到的“Mac本地非Docker环境正常、容器内执行全部失败”的问题，结合你列的测试case，核心原因可以逐个对应：

1. 调用sh执行脚本返回exit 2
   • Mac本地的sh通常是兼容Bash语法的实现（多为软链到Zsh或兼容老版本Bash），所以本地执行能通过；
   • Docker常用的精简基础镜像（比如Alpine、Distroless类）里的sh是BusyBox自带的精简Sh，或者是无Bash兼容能力的Dash，如果你写的排序脚本用了Bash特有语法（比如关联数组、字符串扩展、正则匹配特性），精简Sh会直接在语法解析阶段报错退出，返回exit 2。
2. 调用bash -c 脚本路径 结果文件路径返回exit 2
   • 这是完全是参数顺序错误导致的：Bash的-c参数规则是，紧跟-c的第一个字符串会被当作要执行的完整命令串，后续传入的参数会被识别为这个命令串的位置参数$0、$1，不会被传递给你指定的脚本当入参。
   • 你当前传的参数顺序下，Bash实际执行的逻辑是：把脚本路径当成要直接运行的命令，根本没有加载脚本文件执行，自然会因为找不到命令、路径权限不对等原因报错，返回exit 2。
3. 不带-c的bash 脚本路径 结果文件路径执行成功
   • 这个参数顺序符合Bash的正常执行逻辑：Bash启动后直接加载路径指定的脚本文件执行，把后续的结果文件路径作为$1入参传给脚本，整个流程没有参数误解析，所以能正常运行。

实操层面的修复建议 #

• 提前确认容器内的Shell环境：如果用的是精简镜像，要么选择预装Bash的基础镜像，要么把脚本里的Bash特有语法替换成通用Sh兼容语法，避免解释器不兼容的问题。
• 严格匹配解释器的参数传递规则：直接执行独立脚本文件时，不要多加-c参数，统一用固定顺序的命令数组：[解释器绝对路径, 脚本绝对路径, 脚本所需的全部入参]。
• 不要硬编码解释器的命令名称：不要直接用bash、sh作为命令第一个元素，优先使用容器内实际存在的解释器绝对路径（比如/bin/bash、/usr/bin/bash），避免镜像精简后找不到对应可执行程序的问题。
• 修正进程输出读取逻辑：你当前代码里用bufferedReader.ready()判断是否有输出的写法存在隐患，加上先waitFor()再读流的顺序问题，容易因为进程输出缓冲区塞满导致进程卡死，建议改为启动进程后单独开线程读取输入流和错误流，直到流关闭（readLine()返回null）为止，再执行waitFor()。

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