[Asterisk-Dev] Changes to ast_expr.y

[Steve Murphy]

I've just submitted another patch to the bug site

http://bugs.digium.com/bug_view_page.php?bug_id=0001548

The purpose of this patch is to tweak the new version of ast_expr.y in
CVS (as of yesterday or so), so that when it forms a double-quote
surrounded string into a token, it will not strip away the double-quotes
as new version in CVS now does.

One user reported an issue today, and, with the new patch in place, the
null string comparison can now work two different ways:


exten => _XX.,1,GotoIf($["${calledid}" != ""]?3) 

exten => _XX.,1,GotoIf($[foo${calledid} != foo]?3) 


The second example above is the way suggested by the WIKI. It will 
work as long as there are no spaces in the evaluated value.

The first way should work in all cases, and indeed, might now
be the safest way to handle this situation.

FOR THOSE WHO DON'T LIKE PAGING THRU THE BUG LISTS TO SEE WHAT
CHANGES WERE INTRODUCED IN THE ast_expr.y patches:

1. Double quotes now demarcate a single-token string. So, you have
to be careful now how you use double quotes in these exprs.

2. multiple spaces are now OK. And it doesn't matter where spaces (or
multiple spaces) are. More specifically, you can have spaces at the 
beginning and ending of the $[] expression. BUT YOU STILL NEED AT LEAST
ONE SPACE AROUND and/or IN BETWEEN tokens. Sorry!

So, These expressions are now LEGAL:

exten => _XX.,1,GotoIf($[  "${calledid}"   !=   ""   ]?3) 

BUT THIS ISN'T!:

exten => _XX.,1,GotoIf($["${calledid}"!=""]?3) 
(note the lack of spaces around the != )

3. Better syntax error information:

Syntax errors now output with 3 lines (sorry, my mail composer is very
good at automatically splitting up lines!)

If the extensions.conf file contains a line like:

exten => s,6,GotoIf($[ "${CALLERIDNUM}"  = "3071234567" & 
"${CALLERIDNAME}" : "Privacy Manager" ]?callerid-liar|s|1:s|7)

May  3 15:58:53 WARNING[1234455344]: ast_yyerror(): syntax error: parse
error; Input:
 "3072312154"  : "3071234567" & & "Steves Extension" : "Privacy Manager"
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^
                                  ^

The first line shows the string passed to the expression parser. This
string is the result of the variable replacements, etc. This way, you
can see the actual string that went into the parser.

The second line usually shows a string of '^' chars, that show what's
been legally parsed so far.

And the third line shows where the parser was (lookahead token lexing,
etc), when the parse hit the rocks. A single '^' here. The error is
going to be somewhere between the last '^' on the second line, and the
'^' on the third line. That's right, in the example above, there are two
'&' chars, separated by a space, and this is a definite no-no!

Markster reports the above patch to the patch (1548) is in CVS now.
Please try it out and see if it works for you....

We have some reports in that on RH7.2, the bison can't handle the
input-- I definitely advise that you insure you are using a late-model
bison if you have such probs.

And, one late-coming bug report and fix monday night over spaces NOT
being at the end of the expression... you might want to make sure your
CVS version is up-to-date.

Again, re-update your CVS, and please report any problems you may be
having...


murf