This seems a high-risk change, in that verifying it across all our user's systems is not possible, we'll know if its a problem only when it breaks something that used to work, and its not clear - what actual problem is it fixing? Is there a system on which the current script doesn't work?

Exactly the problem which I described: my system does not have the "which" thirdparty utility installed.

(My system happens to be Arch Linux. The /usr/bin/which program is only a required operating system component on Debian, which I'm not running. I could optionally install GNU which, but it is not available by default and requires manual intervention to install it. This script fails to find any type of python3.* program, and eventually does the fallback on python which does happen to exist.)

...

Furthermore, if it does exist, it might not do what you think it does. For some in-depth discussions on the topic, see https://mywiki.wooledge.org/BashFAQ/081 or https://unix.stackexchange.com/questions/85249/why-not-use-which-what-to-use-then/85250#85250

...

This is not high-risk, since the configure script must be run with /bin/sh and every single /bin/sh on any system anywhere has a builtin shell feature called command -v, as long as it was produced within the last 12 years, and a number of them have had it for much, much longer.
I have listed all the major shells in use today, and confirmed they all support it.

Conversely, the "command -v" shell builtin is required to exist in all POSIX 2008 compliant shells, and is thus guaranteed to work everywhere.

On any POSIX 2008 compliant /bin/sh, a very old standard indeed, command -v must work, and must return a successful exit code when the searched-for command exists as a path or shell function or builtin. You will know if it is a shell function, because it will be defined in your script, which is under your control... you also know that python3.8 is not a shell builtin.

It is literally the definition of portable.

CI: https://ci.nodejs.org/job/node-test-pull-request/31529/ 💚

Using arrays is utterly unacceptable, since this is a /bin/sh script and arrays are not part of the shell command language. They're a bashism, which might work on some systems iff the system /bin/sh happens to be a symlink to bash or ksh or zsh, but this is much less likely to work than the which program...
(If you are willing to depend on #/usr/bin/env bash, then you don't need a fallback since bash will always support command -v. The oldest version of bash I can find to test, bash 1.14 as released in June 1994, supports command -v. Before POSIX required command -v, it was still recommended as a "user portability utilities" option, and bash implemented those.)

GNU autotools has a complex boilerplate routine which uses pure shell to find programs, including routines for detecting whether the $PATH uses the : character or the ; character for splitting elements, and, for kicks, includes support for finding the program with an optional extension such as ".bat" or ".exe" (but since such extensions cannot be reliably probed, it's the responsibility of the system vendor to define a suitable $ac_executable_extensions in their config.site; autotools is common enough that those vendors do indeed create the well-documented config.site). It's only a dozen or two lines. :p

But none of this is necessary unless your actual goal is, like autotools configure scripts, to support building on systems that predate POSIX. And autotools takes their portability very seriously -- they also scrupulously go to pains to use the confusingly ambiguous, deprecated

`command`

form of command substitution, instead of $(command), since it's the only way to ensure autotools works on "the very oldest of non-POSIX-compatible bourne-shells".

Landed in b21556d