On Thu, 19 Mar 2026 16:59:31 GMT, Roger Riggs <[email protected]> wrote:
>> 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. Yes, makes sense. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/30150#discussion_r2966985365
