Summary: | ASTERISK-12678: Function CUT doesn't work if passed as parameter to macro in AEL | ||
Reporter: | Arkadiusz Malka (yarns) | Labels: | |
Date Opened: | 2008-09-03 14:08:20 | Date Closed: | 2008-09-04 18:06:01 |
Priority: | Minor | Regression? | No |
Status: | Closed/Complete | Components: | PBX/pbx_ael |
Versions: | Frequency of Occurrence | ||
Related Issues: | |||
Environment: | Attachments: | ||
Description: | Function CUT do not worik if passed as parameter to macro Sample macro: macro test (abc,cba) { NoOp(${cba}); }; Calling macro: &gsmSelect("testing",${CUT(EXTEN,,3)}); Output from console: [Sep 3 20:58:42] ERROR[6251]: func_cut.c:263 acf_cut_exec: Syntax: CUT(<varname>,<char-delim>,<range-spec>) - missing argument! -- Executing [8-0-693697987@outgoing:4] Macro("SIP/192.168.1.215-c4121d60", "test|"testing"|") in new stack | ||
Comments: | By: Leif Madsen (lmadsen) 2008-09-03 15:25:36 I have gone ahead and reproduced this issue. It appears to be an AEL thing, and not a func_cut thing -- although it could actually be CUT() not accepting or understanding the commas in the dialplan. Here is my extensions.ael and extensions.conf files: extensions.ael: macro test (abc,cba) { NoOp(${cba}); }; context 13416 { 100 => { &test("testing",${CUT(EXTEN,,3)}); }; 101 => { res=${CUT(EXTEN,,3)}; &test("testing",${res}); }; }; extensions.conf: [13416-conf] exten => 102,1,Set(res=$[${CUT(EXTEN,,3)}]) exten => 102,n,Macro(test,"testing",${res}) And here is the output of 'show dialplan': '102' => 1. Set(res=$[${CUT(EXTEN||3)}]) [pbx_config] 2. Macro(test|"testing"|${res}) [pbx_config] [ Context '13416' created by 'pbx_ael' ] '100' => 1. Macro(test|"testing"|${CUT(EXTEN,,3)}) [pbx_ael] '101' => 1. Set(res=$[${CUT(EXTEN,,3)}]) [pbx_ael] 2. Macro(test|"testing"|${res}) [pbx_ael] [ Context 'macro-test' created by 'pbx_ael' ] 's' => 1. Set(abc=${ARG1}) [pbx_ael] 2. Set(cba=${ARG2}) [pbx_ael] 3. NoOp(${cba}) [pbx_ael] I even tried putting in the hyphen in CUT() to see if that helped, but still got the same error. I notice that in 'show dialplan' the commas show up in the pbx_ael lines, but in pbx_config they are converted to pipes (as per 1.4 style) -- so maybe that has something to do with it? Or... this could also be a syntax issue in AEL. I'm not sure about that as I haven't really used AEL much (this was actually my first time in a couple years :)) By: Steve Murphy (murf) 2008-09-04 08:07:06 Sorry to take so long to respond; just thought I'd make note that I am aware of this bug; that I intend to fix it; that I know exactly what's going on, and have a plan (more or less) on how to fix it; that it will take 1-3 days of coding, experimenting, testing, etc. The problem is in the lexical analyzer (flex) spec for 'word'. I need to absorb everything between ${ and } without caring what characters they are. right now, parens are not allowed in 'word' because it would then absorb parens when they are important to recognize as tokens on their own. By: Digium Subversion (svnbot) 2008-09-04 18:05:59 Repository: asterisk Revision: 141094 A branches/1.4/pbx/ael/ael-test/ael-vtest25/ A branches/1.4/pbx/ael/ael-test/ael-vtest25/extensions.ael U branches/1.4/pbx/ael/ael-test/ref.ael-test6 A branches/1.4/pbx/ael/ael-test/ref.ael-vtest25 U branches/1.4/pbx/ael/ael.flex U branches/1.4/pbx/ael/ael_lex.c ------------------------------------------------------------------------ r141094 | murf | 2008-09-04 18:05:50 -0500 (Thu, 04 Sep 2008) | 70 lines (closes issue ASTERISK-12627) Reported by: pj Tested by: murf (closes issue ASTERISK-12678) Reported by: yarns Tested by: murf If you find this message overly verbose, relax, it's probably not meant for you. This message is meant for probably only two people in the whole world: me, or the poor schnook that has to maintain this code because I'm either dead or unavailable at the moment. This fix solves two reports, both having to do with embedding a function call in a ${} construct. It was tricky because the funccall syntax has parenthesis () in it. And up till now, the 'word' token in the flex stuff didn't allow that, because it would tend to steal the LP and RP tokens. To be truthful, the "word" token was the trickiest, most unstable thing in the whole lexer. I was lucky it made this long without complaints. I had to choose every character in the pattern with extreme care, and I knew that someday I'd have to revisit it. Well, the day has come. So, my brilliant idea (and I'm being modest), was to use the surrounding ${} construct to make a state machine and capture everything in it, no matter what it contains. But, I have to now treat the word token like I did with comments, in that I turn the whole thing into a state-machine sort of spec, with new contexts "curlystate", "wordstate", and "brackstate". Wait a minute, "brackstate"? Yes, well, it didn't take very many regression tests to point out if I do this for ${} constructs, I also have to do it with the $[] constructs, too. I had to create a separate pcbstack2 and pcbstack3 because these constructs can occur inside macro argument lists, and when we have two state machines operating on the same structures we'd get problems otherwise. I guess I could have stopped at pcbstack2 and had the brackstate stuff share it, but it doesn't hurt to be safe. So, the pcbpush and pcbpop routines also now have versions for "2" and "3". I had to add the {KEYWORD} construct to the initial pattern for "word", because previously word would match stuff like "default7", because it was a longer match than the keyword "default". But, not any more, because the word pattern only matches only one or two characters now, and it will always lose. So, I made it the winner again by making an optional match on any of the keywords before it's normal pattern. I added another regression test to make sure we don't lose this in future edits, and had to fix just one regression, where it no longer reports a 'cascaded' error, which I guess is a plus. I've given some thought as to whether to apply these fixes to 1.4 and the 1.6.x releases, vs trunk; I decided to put it in 1.4 because one of the bug reports was against 1.4; and it is unexpected that AEL cannot handle this situation. It actually reduced the amount of useless "cascade" error messages that appeared in the regressions (by one line, ehhem). There is a possible side-effect in that it does now do more careful checking of what's in those ${} constructs, as far as matching parens, and brackets are concerned. Some users may find a an insidious problem and correct it this way. This should be exceedingly rare, I hope. ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=141094 |