On Mon, 9 Mar 2026 20:56:15 GMT, Roger Riggs <[email protected]> wrote:
> Test java/lang/ProcessBuilder/Basic.java fails with 'Exception: > java.lang.Error: PATH search algorithm" > The tests in ProcessBuilder.Basic related to PATH search algorithm use the > system binaries for /bin/true and /bin/false. > The tests proceed to copy the binaries to different directories on carefully > constructed PATHs and verify the correct one is found. > On some Linux OS's the binaries for /bin/true and /bin/false are the same > binary. Distinguished only by arg[0] when executed. > On Ubuntu 25-10, copying the binary to `prog` and launching it, results in > the exit status not being the expected value. > Musl and Apline systems have other limitations that are already reflected in > special cases. > A solution proposed here is to provide separate binaries for the true and > false functions so their invocation is more controlled. > > Use native BasicTrue and BasicFalse executables in cases where /bin/true and > /bin/false are not unique. test/jdk/java/lang/ProcessBuilder/Basic.java line 710: > 708: setFileContents(trueExe, "#!/bin/true\n"); > 709: trueExe.setExecutable(true); > 710: } I wonder what the benefit is of this triple safety here (use OS true, use our own true, use shell script). Is there any benefit of one over the other? And would finding BasicTrue ever fail? And if it failed, would that not be a test setup error? The last condition could hide such an error indefinitly. I'd probably just use OS true, then BasicTrue. Or even just BasicTrue outright. Unless you want to test PATH resolution for OS binaries? But that should then be a separate test, since whether or not it gets executed depends on whether the OS happens to use multi-call bins. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/30150#discussion_r2951570526
