Summary:ASTERISK-00449: [patch] More sophisticated expression parsing
Reporter:Paul Cadach (pcadach)Labels:
Date Opened:2003-10-28 23:17:18.000-0600Date Closed:2011-06-07 14:05:10
Versions:Frequency of
Environment:Attachments:( 0) ast_expr.y.diff
1) allow quoted variables which contains spaces (like GotoIf($['${CALLFILENAME}' = '${FOO}']?5:2);
2) don't require spaces between variable name and operation.
Comments:By: John Todd (jtodd) 2003-10-28 23:34:14.000-0600

I'm afraid I don't understand why you would need variables with spaces in them.  Your example does not show an example, either.

As for fixing the requirement for spaces around an operator, I don't see that as a huge problem.  Is it preventing you from doing some particular function that requires no spaces?  

I appreciate the bugfixes, but I am not completely clear on why they would need to be implemented.  Can you explain more?

By: Paul Cadach (pcadach) 2003-10-29 00:14:05.000-0600

I've just used a part of dialplan to enable call monitoring found somewhere in the Net. This is an example:

exten => s,1,AGI(set-timestamp.agi)
exten => s,2,SetVar(CALLFILENAME=${timestamp}-${ARG2}-${ARG1})
exten => s,3,Monitor(wav,${CALLFILENAME})

exten => s,1,GotoIf($['${CALLFILENAME}' = '${FOO}']?5:2)
exten => s,2,SetVar(MONITORDIR=/var/spool/asterisk/monitor)
exten => s,3,System(/usr/bin/soxmix '${MONITORDIR}/${CALLFILENAME}-in.wav' '${MONITORDIR}/${CALLFILENAME}-out.wav' '${MONITORDIR}/${CALLFILENAME}.wav')
exten => s,4,System(/bin/rm '${MONITORDIR}/${CALLFILENAME}-in.wav' '${MONITORDIDIR}/${CALLFILENAME}-out.wav')
exten => s,5,Hangup

exten => _.,1,Macro(record-on,${EXTEN},${CALLERIDNUM})
exten => _.,6,Goto(default-post,${EXTEN},1)

Someone can specify spaces in callerid, so generated filename will contains spaces too. To make this mechanism working you must:
1) quote filenames to pass them to sox/rm;
2) quote filenames to pass them to '=' operator (in macro-record-cleanup).

To make quoting working lexical analyzis was re-written, and as a "side-effect" ;-)' spaces no longer required around operators.

By: Tilghman Lesher (tilghman) 2004-03-19 13:57:43.000-0600

Small problem:  how to distinguish between:

${CHANNEL} where CHANNEL is SIP/blahblah-0123
$[${i} - 1] where you're trying to compute the value of i minus one

See, you've got a "-" in both places, but in one place it's just a character and in the other place it's an operator.  How are the two distinguished?

By: Paul Cadach (pcadach) 2004-03-19 14:06:57.000-0600

If you don't want to evaluate '-' in the string - just quote it.

By: Tilghman Lesher (tilghman) 2004-03-20 21:01:56.000-0600

I don't think this patch is going to make it in, for the simple fact that it breaks backward compatibility.  So if a dialplan does a comparison on a string which contains one of the evaluation characters, it's going to break during a CVS upgrade.

Perhaps you could modify the patch such that quote marks can be used in strings, but make spaces around operators still mandatory?

Or run around the problem the patch is trying to solve a different way - such as by running a substitution on the variable before comparison (e.g. translating a space to another character, such as a plus or a tilde).  We could even do this with an inline function, e.g. ${SUBSTITUTE(varname:<space>:~)}

By: Brian West (bkw918) 2004-03-20 21:06:39.000-0600

I agree with Corydon on this one we can't break backwards compatibility.

By: Paul Cadach (pcadach) 2004-03-21 12:53:52.000-0600

${CHANNEL} will not be evaluated until it will be used inside an expression (i.e. $[] construction). But contructions $[${CHANNEL} - 1] and $[${CHANNEL}-1] will produce the same results - a warning "non-numeric argument", $[${i} - 1} and $[${i}-1] will be the same too until variable 'i' is integer.

Also, variable substitution could be done at parser level, where all possible problems could be fixed (because you could distinguish variables between strings and integers, and evaluate expression in dependence of operator's argument types).