Re: [SCM] GNU Libtool branch, master, updated. v2.4.2-141-g4099c12

[Stefano Lattarini]

Hi Eric.

On 12/19/2011 02:44 PM, Eric Blake wrote:
> On 12/17/2011 10:22 PM, 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]}))" \
> This MUST be hidden behind an eval.  Otherwise, shells like Solaris
> /bin/sh will choke on trying to parse this line:
>
> $ /bin/sh -c 'echo "$((${BASH_VERSINFO[0]}*1000 + \
>      ${BASH_VERSINFO[1]}))"'
> /bin/sh: bad substitution
In truth, for Solaris /bin/sh, protecting the problematic construct with 
an "if"
clause is enough:

 $ /bin/sh -c 'if false; then \
     echo "$((${BASH_VERSINFO[0]}*1000 + ${BASH_VERSINFO[1]}))"; \
   fi; \
   echo OK'
 OK

But, as I've shown, that is not enough for dash and NetBSD /bin/sh:

 $ dash -c 'if false; then \
     echo "$((${BASH_VERSINFO[0]}*1000 + ${BASH_VERSINFO[1]}))"; \
   fi; \
   echo OK'
 dash: Syntax error: Bad substitution

So you're still right about the need to use an eval (or to rework the 
code so that
it doesn't try to to reference array variables).

Regards,
  Stefano