On 2020-07-01 12:05, Galder Zamarreno wrote:
Using `which` to check whether commands exist can result in confusing
errors when `which` itself is not installed in the system. This is the case
with `autoconf`, where if `autoconf` is present but `which` isn't, the
build system says that `autoconf` is missing, when in reality it is `which`
which is missing. The fix switches autoconf uses of `which` for `type -p`
instead, which is a Bash built-in command.
I've tested the fix with a fedora docker container that had `autoconf`
installed but `which`. When using `type -p` it correctly detects `autoconf`
installed and eventually fails saying that `which` is not installed, which
is the expected behaviour.
`which` is still in use in make/autoconf/util_windows.m4. A possible future
improvement would be to see if `which` use there could be replaced as well.
Eventually, when no `which` uses remain, the presence check for `which`
could be removed.
I agree that we should replace "which" with "type -p" everywhere. The
best way to do this is probably to replace the value of $WHICH with
"type -p". It's a bash built-in, so we can count on its presence. If you
want to fix that as part of this bug, I'm ok with it, otherwise we
should open a new bug to track this. I think there is also one or two
instances of "command" recently added as (better, but not as good as
"type -p") replacements for which.
/Magnus
Bug: https://bugs.openjdk.java.net/browse/JDK-8248158
WebRev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8248158/01/webrev/
Galder
