[PATCH 2 of 2 V2] tests: don't hardcode path to bash interpreter

[David Soria Parra]

Martin Geisler <martin at geisler.net> writes:

> Olle Lundberg <olle.lundberg at gmail.com> writes:
>
>> # HG changeset patch
>> # User Olle Lundberg <geek at nerd.sh>
>> # Date 1395785272 -3600
>> #      Tue Mar 25 23:07:52 2014 +0100
>> # Node ID c0c158e277f7b7a33c51d0ee163c42345c70d84d
>> # Parent  6e8b538637302e06a3510d15e36c30757f8501a2
>> tests: don't hardcode path to bash interpreter
>>
>> Use the env binary to figure out the correct bash to use.
>> Certain systems ships with an ancient version of bash, but the
>> user might have installed a newer one that is earlier in $PATH.
>>
>> For example the current version of Mac OS X ships version 3.2.51
>> of bash, which does not understand new fancy builtins such as
>> readarray. A user might install a newer version of bash, use that
>> as their shell and add that path before bin.
>
> Okay, but couldn't one object that the scripts we distribute shouldn't
> use new fancy features?
Yes we should try to be /bin/sh compatible.

> Infact, it seems like it would be better if we used #!/bin/sh instead
> and wrote the scripts so they work on a wide vararity of machines.
>
> I haven't really looked at the shell scripts, so I don't know if we
> already use non-standard features or if it would be difficult to rewrite
> them to a simpler form of shell script.
revsetbenchmark.sh does use bash arrays which is a bash 4. I agree
we should work on more compatible shell scripts as at least some unixes
like Solaris & co won't have a /bin/bash. Also there are plenty of
pre-bash 4 RHEL, etc around. I think olles approach is sensible
though. Until we fix the scripts to not use bash, we should use
/usr/bin/env to find bash.