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

[Gary V. Vaughan]

Hi Stefano,

On 18 Dec 2011, at 17:19, Stefano Lattarini wrote:
> On 12/18/2011 11:07 AM, Gary V. Vaughan wrote:
>> 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.

Not that I've looked at the implementation, but isn't eval as bad as a fork on
Windows? (which is the only reason to avoid forks, since they are extremely 
cheap on
Unix.)

> 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

Ah, true... I guess I was too focussed on a straight forward one liner, and 
missed
the obvious one.  D'oh!  I'll switch to that and push presently.

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)