On Thu, 19 Mar 2026 05:30:42 GMT, Thomas Stuefe <[email protected]> wrote:
>> The change is minimally changing the test environment, since testing some of >> the lesser known Linux variants are not easy to come by. >> Using the OS true/false is a non-starter on Ubuntu 25-10 and on Musl due to >> the multi-exe construction on those platforms. >> The identified binary must be able to be copied to different directories and >> different names and still have the correct exit status. >> >> Settling back to using only the BasicTrue/BasicFalse binaries is likely to >> be stable after potential failures in porting to the other platforms. > > Okay. I would have thought that you don't need that many different Linux > variants if you roll your own solution: don't rely on system true+false, and > don't rely on the installed shell. If you just compile your own program and > run it, you minimize the dependencies on the target OS - the only thing you > depend on then is the kernel and libc. > > One thought I had was do we even need two programs, true and false? You could > just provide a single program (the self-written variant) that returns maybe > something more exciting than 0 or 1. You could even hand in the exit code as > an argument to the program. Lets call it "mirror", and "mirror 26" returns 26 > as exit code. Then, use a random input argument and check that this random > number is the exit code of the child process. > > That way, you can be sure the PATH resolution really got your mirror program, > and you don't need to juggle two programs around. > > This is just an idea. If you want to reduce the changes in this PR, I am fine > with your current solution. The test here is of the resolution of an executable in the PATH. The test needs to be able to distinguish executing a program with the same name and arguments that appears in more than one PATH element. So, it can't depend on the command line arguments or program name to verify the correct program was invoked. (Each could produce different output, but that's more complex to read and check than the exit status). The more the test provides of the test environment, the further the test is from the real operating system components and that's a **bad** thing since we're trying to verify that when an application provides a PATH, the correct program is invoked. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/30150#discussion_r2961428582
