On 12/18/2011 06:33 AM, Gary V. Vaughan wrote: >>> 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:
Yes - hiding behind eval is the only way to use shell extensions that
not all shells will parse.
>>
>> 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.)
No. eval doesn't fork.
>
>> 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.
--
Eric Blake ebl...@redhat.com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
