On Thu, Jul 2, 2020 at 2:30 AM Magnus Ihse Bursie < magnus.ihse.bur...@oracle.com> wrote:
> > > 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. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8248158 > > WebRev: > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8248158/01/webrev/ > You don't need the grep part. "type -p" is well-defined to return > nothing, or the path to the binary. The grep was needed for which on > solaris, which returned this as an error message when a binary was not > found, instead of nothing. > Thanks for the info. I've updated my local changes and it worked as expected within the docker container. > > /Magnus > > > > Galder > >