RFR: 8325576: java/lang/ProcessHandle/InfoTest.java fails on systems with coreutils with --enable-single-binary [v2]

[Roger Riggs]

On Tue, 13 Feb 2024 18:24:10 GMT, Dan Lutker <dlutker at openjdk.org> wrote:

>> To be fair, this looks similar to what `isMusl()` does: searching for strings in outputs. But I do wonder if `--help` would include "sleep" for some innocuous description somewhere, and this code would accidentally match. @lutkerd, what's the output for `coreutils --help` for a single executable binary?
>
>> what's the output for `coreutils --help` for a single executable binary?
> 
> 
> # coreutils --help
> Usage: coreutils --coreutils-prog=PROGRAM_NAME [PARAMETERS]... 
> Execute the PROGRAM_NAME built-in program with the given PARAMETERS.
> 
>       --help     display this help and exit
>       --version  output version information and exit
> 
> Built-in programs:
>  [ arch b2sum base32 base64 basename basenc cat chcon chgrp chmod chown chroot cksum comm cp csplit cut date dd df dir dircolors dirname du echo env expand expr factor false fmt fold ginstall groups head hostid id join link ln logname ls md5sum mkdir mkfifo mknod mktemp mv nice nl nohup nproc numfmt od paste pathchk pinky pr printenv printf ptx pwd readlink realpath rm rmdir runcon seq sha1sum sha224sum sha256sum sha384sum sha512sum shred shuf sleep sort split stat stdbuf stty sum sync tac tail tee test timeout touch tr true truncate tsort tty uname unexpand uniq unlink users vdir wc who whoami yes
> 
> Use: 'coreutils --coreutils-prog=PROGRAM_NAME --help' for individual program help.
> 
> GNU coreutils online help: <https://www.gnu.org/software/coreutils/>
> Report any translation bugs to <https://translationproject.org/team/>
> Full documentation <https://www.gnu.org/software/coreutils/coreutils>
> or available locally via: info '(coreutils) Multi-call invocation'
> 
> 
> This test is about parameter checking, so I am inclined to agree with @ecki and not check the process name or change the exe.

At the time `sleep` seemed ubiquitous and was native so it ran quickly. (Much quicker than running java).
Running another program would be fine.  For example ,selecting an executable based on the OS type and giving the expected string in the output would be preferred.
The isBusyBox check is also a bad hack, but lighter weight since its not executing a program.
As the number of minor variations of platforms appear a more general approach would be useful.

I'd code it all in the test itself, doing a lookup based on the operating system name with the respective executable and expected string in the info arguments[0].
(With a fallback to sleep, so the table does not have to list every os).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17798#discussion_r1488468243