Summary:	ASTERISK-10843: AEL macro argument variables aren't properly quoted when set
Reporter:	Ben Winslow (rain)	Labels:
Date Opened:	2007-11-20 15:40:10.000-0600	Date Closed:	2008-01-11 14:09:43.000-0600
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	PBX/pbx_ael
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) pbx_ael-macro-quoting-fix.diff
Description:	When the dialplan code is generated to set a macro's variables, the argument data isn't properly escaped, causing the loss of any quoting in the macro.  For example, if the macro in the 'additional information' field was called like so: &foo(abc "def" geh); ...the following message would be logged: I got [abc def geh] but I want it to look like [abc "def" geh] The easiest fix is probably to wrap ${ARGn} inside a ${QUOTE()} in the generated dialplan code. ****** ADDITIONAL INFORMATION ****** macro foo(bar) { Verbose(I got [${bar}] but I want it to look like [${ARG1}]); }
Comments:	By: Ben Winslow (rain) 2007-11-20 15:41:13.000-0600 The attached patch fixes the issue as suggested in the bug report. By: Steve Murphy (murf) 2007-11-27 15:42:14.000-0600 I'm sorry to be thick-headed on this, but I have to wonder. We've been passing in args to macros this way ever since AEL first version, and this sort of change could take all sorts of users by surprise. Is it possible for you to pass QUOTE(arg data) into the macro call yourself? &macrocall(blah,QUOTE(hi "mom" there),ehlo); ?? By: Steve Murphy (murf) 2007-11-28 17:23:31.000-0600 Without a quick response, I'm going to close this bug, assuming that you can call the macro with the QUOTE() function call in the args to get the effect you are seeking. If this is not the case, please reopen this bug, and we'll figure something out. By: Ben Winslow (rain) 2007-11-29 09:34:27.000-0600 The problematic macro is one I created for debug logging -- having to wrap it all in ${QUOTE()} negates the code simplification of using a macro in the first place. So long as the bug is retained for compatibility, though, I suppose I can just use ${ARGn} in the macro and fix by re-calling Set(). By: Steve Murphy (murf) 2008-01-11 14:09:43.000-0600 Sorry, but if I change this now, we'll have an armed uprising. It could easily cause some really unexpected, strange problems for users.