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? Cheers, -- Gary V. Vaughan (gary AT gnu DOT org)