Arch Linux

The upstream script uses /usr/bin/env bash, but then performs some sed magic to post-process the script for entirely illegitimate reasons. According to the ./configure output when trying to rebuild the package (this is the thing which sets up the terrible sed magic) it has decided to detect that /bin/sh is the canonical path to the bash interpreter:

Checking for bash... Yes (/bin/sh).

This is very very wrong, and it's upstream's fault. I'm unsure how they managed it though.

Since Arch Linux does not "officially" support /bin/sh as anything other than a symlink to bash, and this isn't our script in the first place, this isn't really actionable for us. Please ask upstream to fix their script.

Actually I do know how they managed it, they have a fundamental lack of understanding of how bash works:

BASH=${BASH:-bash}

[...]

printf "Checking for bash... "
if command -v ${BASH} > /dev/null; then
have_bash=1
bash_absolute=$(command -v ${BASH})
printf "Yes (%s).\n" "$bash_absolute"
else
have_bash=0
printf "No. (%s not found)\n" "${BASH}"
fi

This is illegitimate and is documented by the bash manpage as:

BASH Expands to the full filename used to invoke this instance of bash.

It MUST not be used as anything other than the path to this one specific instance of the bash interpreter. Embedding it into build artifacts is not permitted, you cannot rely on it.

But the configure script allows this variable to do double duty as an internal implementation detail of the bash shell, as well as a means to pass options to the configure script. Which does not work as if the bash shell is used to run the configure script, it will override any attempt to configure it (and on systems where /bin/sh is a bash interpreter, it will get it very, very wrong in the process).

This configure check never works as intended, and needs to be fixed. Once it is fixed, the upstream script will work properly, even on Arch. Please submit an upstream bug.