The asterisk expression parser has undergone some evolution. It is hoped
that the changes will be viewed as positive.
The "original" expression parser had a simple, hand-written scanner,
and a simple bison grammar. This was upgraded to a more involved bison
grammar, and a hand-written scanner upgraded to allow extra spaces,
and to generate better error diagnostics. This upgrade required bison
1.85, and part of the user community felt the pain of having to
upgrade their bison version.
The next upgrade included new bison and flex input files, and the makefile
was upgraded to detect current version of both flex and bison, conditionally
compiling and linking the new files if the versions of flex and bison would
allow it.
If you have not touched your extensions.conf files in a year or so, the
above upgrades may cause you some heartburn in certain circumstances, as
several changes have been made, and these will affect asterisk's behavior on
legacy extension.conf constructs. The changes have been engineered
to minimize these conflicts, but there are bound to be problems.
The following list gives some (and most likely, not all) of areas
of possible concern with "legacy" extension.conf files:
- Tokens separated by space(s).
Previously, tokens were separated by spaces. Thus, ' 1 + 1 ' would evaluate
to the value '2', but '1+1' would evaluate to the string '1+1'. If this
behavior was depended on, then the expression evaluation will break. '1+1'
will now evaluate to '2', and something is not going to work right.
To keep such strings from being evaluated, simply wrap them in double
quotes: ' "1+1" '
- The colon operator. In versions previous to double quoting, the
colon operator takes the right hand string, and using it as a
regex pattern, looks for it in the left hand string. It is given
an implicit ôperator at the beginning, meaning the pattern
will match only at the beginning of the left hand string.
If the pattern or the matching string had double quotes around
them, these could get in the way of the pattern match. Now,
the wrapping double quotes are stripped from both the pattern
and the left hand string before applying the pattern. This
was done because it recognized that the new way of
scanning the expression doesn't use spaces to separate tokens,
and the average regex expression is full of operators that
the scanner will recognize as expression operators. Thus, unless
the pattern is wrapped in double quotes, there will be trouble.
For instance, ${VAR1} : (WhoWhat*)+
may have have worked before, but unless you wrap the pattern
in double quotes now, look out for trouble! This is better:
"${VAR1}" : "(WhoWhat*)+"
and should work as previous.
- Variables and Double Quotes
Before these changes, if a variable's value contained one or more double
quotes, it was no reason for concern. It is now!
- LE, GE, NE operators removed. The code supported these operators,
but they were not documented. The symbolic operators, =, =, and !=
should be used instead.
- Added the unary '-' operator. So you can 3+ -4 and get -1.
- Added the unary '!' operator, which is a logical complement.
Basically, if the string or number is null, empty, or '0',
a '1' is returned. Otherwise a '0' is returned.
- Added the '= ' operator, just in case someone is just looking for
match anywhere in the string. The only diff with the ':' is that
match doesn't have to be anchored to the beginning of the string.
- Added the conditional operator 'expr1 ? true_expr : false_expr'
First, all 3 exprs are evaluated, and if expr1 is false, the 'false_expr'
is returned as the result. See above for details.
- Unary operators '-' and '!' were made right associative.
lmadsen
2010-01-14