[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Portability of shell parameter expansions (${word%pattern} and frien
From: |
Ralf Wildenhues |
Subject: |
Re: Portability of shell parameter expansions (${word%pattern} and friends)? |
Date: |
Tue, 6 Nov 2007 18:22:37 +0100 |
User-agent: |
Mutt/1.5.17 (2007-11-04) |
* Benoit Sigoure wrote on Tue, Nov 06, 2007 at 03:33:49PM CET:
>
> By the way, while we're at it, how portable is $((math expression))? It
> also saves lots of forks compared to `expr whatever`.
Same issue. You should be able to factorize likewise with shell
functions, similar to Libtool's approach:
# ac_func_arith
# -------------
# Arithmetic evaluation, avoids expr if the shell is sane.
#
# subshell and eval are needed to keep Solaris sh from bailing out:
if ( eval 'test $(( 1 + 1 )) = 2' ) 2>/dev/null; then
# With "$@", bash does not split positional parameters:
eval 'ac_func_arith ()
{
ac_func_arith_result=$(( $* ))
}'
else
ac_func_arith ()
{
ac_func_arith_result=`expr "$@"`
}
fi
# usage: avoid result=`ac_func...` to avoid fork
ac_func_arith 3 + 5
echo $ac_func_arith_result
Of course that limits you to the set of expressions common to both
methods, so instead of `3+5', use `3 + 5', and so on.
The above could help save a few forks in Autotest (plus one per test)
and some in _AC_FEATURE_CHECK_LENGTH, _AC_COMPUTE_INT_COMPILE (when
Autoconf starts to use shell functions).
Cheers,
Ralf