On 12/18/2011 11:07 AM, Gary V. Vaughan wrote:
Hi Stefano,
On 18 Dec 2011, at 17:02, Stefano Lattarini wrote:
On 12/18/2011 10:52 AM, Stefano Lattarini wrote:
On 12/18/2011 06:15 AM, Gary V. Vaughan wrote:
+# We should try to minimise forks, especially on Windows where they are
+# unreasonably slow, so skip the feature probes when bash is being used:
+if test set = "${BASH_VERSION+set}"; then
+ : ${lt_HAVE_ARITH_OP="yes"}
+ : ${lt_HAVE_XSI_OPS="yes"}
+ # The += operator was introduced in bash 3.1
+ test -z "$lt_HAVE_PLUSEQ_OP" \
+&& test 3000 -lt "$((${BASH_VERSINFO[0]}*1000 + ${BASH_VERSINFO[1]}))" \
+&& lt_HAVE_PLUSEQ_OP=yes
+fi
This will likely break with dash 0.5.2:
$ cat foo.sh
#!/bin/sh
if test set = "${BASH_VERSION+set}"; then
: ${lt_HAVE_ARITH_OP="yes"}
: ${lt_HAVE_XSI_OPS="yes"}
# The += operator was introduced in bash 3.1
test -z "$lt_HAVE_PLUSEQ_OP" \
&& test 3000 -lt "$((${BASH_VERSINFO[0]}*1000 + ${BASH_VERSINFO[1]}))" \
&& lt_HAVE_PLUSEQ_OP=yes
fi
$ dash foo.sh
foo.sh: 7: Syntax error: Bad substitution
Update: the same happens with NetBSD 5.1 /bin/sh (which is probably
an ash-derivative).
Thanks for the report.
Unfortunately, I'm out of ideas on how to portably detect the bash version
without
spending a fork, in which case it seems easiest to spend that fork actually
testing
for += support rather than poking at the bash version.
Can anyone think of something better than just removing the whole
lt_HAVE_PLUSEQ_OP
clause from the patch quoted above, and letting the shell figure it by itself
later
on?
Adding an extra eval seems to do the trick:
eval 'test 3000 -lt "$((${BASH_VERSINFO[0]}*1000 +
${BASH_VERSINFO[1]}))"'
Of course, a comment about why this eval is needed would be definitely
warranted.
Or, to be even safer, you could directly poke at $BASH_VERSION instead:
case $BASH_VERSION in
[12].*|3.0.*) ;;
*) lt_HAVE_PLUSEQ_OP=yes;;
esac
Regards,
Stefano
