Summary:	ASTERISK-20723: Asterisk warns about pipe characters in string variable created using Set
Reporter:	Cam (cam)	Labels:
Date Opened:	2012-11-24 03:10:12.000-0600	Date Closed:	2012-11-24 16:01:00.000-0600
Priority:	Minor	Regression?
Status:	Closed/Complete	Components:	Core/PBX
Versions:	1.8.18.0	Frequency of Occurrence
Related Issues:
Environment:	Asterisk 1.8.18.0 on a i686 running CentOS Linux 5.5	Attachments:
Description:	Consider these two lines of dialplan: {noformat} exten => s,n,Set(regx=^1?8(00|22|33|44|55|66|77|88)[2-9][0-9]{6}$) exten => s,n,GotoIf($[${REGEX("${regx}" ${OUTNUM})} = 1]?tollfree) {noformat} When these are executed, the Asterisk CLI shows this warning after the first of the two lines (the Set statement): {noformat} [2012-11-24 03:41:26] WARNING[13479]: pbx.c:1442 pbx_exec: The application delimiter is now the comma, not the pipe.  Did you forget to convert your dialplan?  (Set(regx=^1?8(00|22|33|44|55|66|77|88)[2-9][0-9]{6}$)) {noformat} Since at this point we are only putting a string into a string variable, Asterisk should not be complaining about the contents, since that string might be used for any number of purposes totally unrelated to the Asterisk dialplan.  In this particular case the pipe characters are being used in a regular expression, which is still valid usage, but Asterisk doesn't yet know that when the Set statement is invoked. Strangely, this only happens on one of two Asterisk systems, both running the exact same version of Asterisk and running the identical two lines shown above.  Both were compiled using the same options in menuselect, so I have no idea why one spits out this error and not the other.
Comments:	By: Michael L. Young (elguero) 2012-11-24 10:47:29.269-0600 Are the asterisk.conf settings identical on both machines?  If the "dontwarn" option is not enabled, then this error message will be displayed. Is the string being stored properly?  Is it just the warning messaging that you are getting? By: Cam (cam) 2012-11-24 11:08:18.859-0600 The asterisk.conf settings are nearly identical.  The only difference is that on the one that doesn't show the warning, there is an additional line in the directories section (astdatadir => /var/lib/asterisk).  There is no mention of a "dontwarn" option in either, so I would assume that takes the default setting.  Is there any other setting in any other file that could affect this? The string IS getting stored correctly and everything apparently works as it should.  It is just the warning message that is out of place. Adding dontwarn=yes to asterisk.conf does make the warnings stop. By: Michael L. Young (elguero) 2012-11-24 16:01:00.130-0600 Thanks for responding back. I did take a look at the code and that is what prompted me to point out that option to turn off the warning.  We are going to go ahead and close this out since it would appear that everything is working as it should. By: Cam (cam) 2012-11-25 13:31:18.240-0600 Michael, with all due respect, I disagree that this is not a bug.  You may not think it worthy of your time or effort, but the fact is that as long as it persists, people have two choices: Either live with the erroneous warnings, or turn off warnings and possibly miss valid ones that should be of concern.  Since most users ignore warnings anyway, you may feel that turning off warnings is an acceptable solution, but it's certainly not an ideal solution.  It may be a minor bug in that it doesn't affect the operation of Asterisk, but it's still a bug. By: Michael L. Young (elguero) 2012-11-25 13:45:07.669-0600 Cam, the reason why it is not a bug is that the code was programmed for what you want.  There is a specific check on this particular warning to see if that option is set.  It is not turning off all warnings.  Only warnings that might be considered "optional" or harmless such as this one.  Also, not everyone is going to get this warning.  It is only displayed when someone uses the pipe character.  Not all users are using strings in the way you are.  So, it is not that I don't think it worthy of time and effort, it is that the code specifically was already written to handle this situation for you and those who have this warning being displayed.  Obviously, someone else had already thought about the fact that this warning you are getting was harmless and if someone chose to turn it off, they could do so.