Re: FYI [PATCH] libtool: minimise forks per invocation under bash.

[Gary V. Vaughan]

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)