[Home]

Summary:ASTERISK-06773: extensions.conf parser cannot handle certain global variable names
Reporter:Jeremy Lingmann (lingmann)Labels:
Date Opened:2006-04-13 10:36:00Date Closed:2006-04-13 10:51:52
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:The extensions.conf parser has problems with certain global variables.  For example:

---------- begin extensions.conf ----------
[general]
clearglobalvars=yes

[global]
CALLERID_MYGLOBAL=123
REGULAR_GLOBAL=456

[somecontext]
exten => s,1,NoOp(CALLERID_MYGLOBAL: ${CALLERID_MYGLOBAL})
exten => s,n,NoOp(REGULAR_GLOBAL: ${REGULAR_GLOBAL})
---------- end extensions.conf ----------

This results in the following output:
 -- Executing NoOp("IAX2/pbx-1", "CALLERID_MYGLOBAL: ") in new stack
 -- Executing NoOp("IAX2/pbx-1", "REGULAR_GLOBAL: 456") in new stack

Apparently, we can't access the value of CALLERID_MYGLOBAL.  I believe this is because the parse tree is interpreting the stuff inside ${} as the CALLERID function.  However, if this is the expected behavior, this is not intuitive and not documented well (if at all).   Here is about the only thing I could find in README.variables:

---------- begin README.variables ----------
There are two reference modes - reference by value and reference by name.
To refer to a variable with its name (as an argument to a function that
requires a variable), just write the name. To refer to the variable's value,
enclose it inside ${}.
---------- end README.variables ----------

RANT: To Digium and Asterisk developers... Please, Please, PLEASE put a top priority on moving towards AEL or something better as the standard extensions language.  I used to be a big fan of Asterisk and the whole idea of an open source PBX...  However, little issues like this just make me shake my head.  There are a lot of excellent languages and syntaxes out there already... why not use one???
Comments:By: Tilghman Lesher (tilghman) 2006-04-13 10:51:52

Fixed in the latest 1.2 branch (not in 1.2.7).  Trunk uses a different implementation, so this case was already handled.

BTW, this had nothing to do with the extensions.conf parser, but rather with the core variable substitution code.  So moving to AEL would have made no change to this issue.