Steve Murphy
2004-Mar-26 12:01 UTC
[Asterisk-Users] Solution== CALLERIDNAME and GotoIf -- Quoting Question
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