[Asterisk-Users] Solution== CALLERIDNAME and GotoIf -- Quoting Question

[Steve Murphy]

Solved my problem, but... you may not like the way I did it.

I dived into the yacc code for the humble ast_expr, and found a few
nits, and cleared them up, and submitted a bug report with a patch:

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

Now, here's my complaints about the $[  ]  expression parsing:

1. It uses a space, and only a space to end a token. All tokens must be
followed by exactly one space. No spaces may preceed the whole
expression (the $[ can't have a space after it). No spaces between the
last token and the closing ']'.  Two spaces in a row will result in a
syntax error, most likely.

2. No variables that might contain a space are advisable. Unless of
course, it works out nicely syntax wise, which would be fairly rare, I'd
think, but who knows.

3. Double quotes are meaningless.

4. Error messages are wanting. All you get is the fact that a parse
error occurred.  -- Which is good, but doesn't help you much if you
don't know what the parse error could be.

My solution:

1. Ignore leading spaces before a token.

2. Match a double quote to the next double quote, and call what's inside
a single token, spaces or no spaces. (the double quotes are not included
in the token).

3. Null tokens are ignored (trailing spaces).

4. A parse error prints out what it was parsing, and where it was in the
string, when the error occurred.

Now, this kind of thing is possible/legal and works as imagined:

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

(Pardon the obligatory inserted newline by my mail package!).

Since the evaluation pass doesn't seem to care about ""'s either, 
the "${CALLERIDNAME}"  evaluates to "MURPHY S   ", as hoped.


I've been running my new version of the expression parser for a while
now, and all seems well. I've tested both the "true" and "false"
branches. The changes I made should be upwards compatible. (Old stuff
should parse as usual.) I can't think of any cases where double quotes
might occur that things wouldn't work now... well, maybe just one, for a
null token ("" parses to a null token, and will be ignored, which might
raise a syntax error... The wiki describes this and advises the use of
something like xxx"${VAR}" = xxx for cases like this... but you guys
know more than I do... let me know.


murf


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.digium.com/pipermail/asterisk-users/attachments/20040326/5c9ef9ce/attachment.pgp