On Tue, 13 Feb 2024 18:24:10 GMT, Dan Lutker <dlut...@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

Reply via email to