[Home]

Summary:ASTERISK-03397: Regular Expression matching operator : not working as described in the documentation.
Reporter:eko1 (eko1)Labels:
Date Opened:2005-01-31 11:07:58.000-0600Date Closed:2005-02-06 21:42:49.000-0600
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:I have a context with the following:

exten => s,1,noop($[${ARG1} : \(1.\+\)|011\(.\+\)])

According to the documentation of the : operator:

If the match succeeds and the pattern contains at least one regular expression subexpression `\(...\)', the string corresponding to `\1' is returned;

If ARG1 is 1987654321 it returns 1987654321. However, if ARG1 is 011987654321, it returns 12 (i.e. the number of characters matched). I was expecting it to return 987654321 because of the subexpression \(.\+\). This is probably caused by the regex engine not recognizing the subexpression after the |.
Comments:By: Brian West (bkw918) 2005-01-31 11:19:48.000-0600

You might need to escape the | like \|

bkw

edited on: 01-31-05 13:25
By: Kevin P. Fleming (kpfleming) 2005-01-31 12:38:19.000-0600

Brian is right, that's probably what needs doing. In addition, someone with more privileges than me needs to move this bug to the Core Asterisk project, it's not SIP-related at all.
By: eko1 (eko1) 2005-01-31 15:31:26.000-0600

I wanted to place this bug in a more appropriate category but I was not able to select one. Anywho...

I have

exten => s,1,noop($[${ARG1} : \(1.\+\)\|011\(.\+\)])

and I get the same thing. A 'show dialplan' shows it as:

's' =>            1. noop($[${ARG1} : (1.+)|011(.+)])           [pbx_config]

so escaping the | didn't help.
By: Brian West (bkw918) 2005-01-31 16:26:40.000-0600

well noop doesn't do anything with it... so wouldn't this apply to a gotoif maybe?
By: Brian West (bkw918) 2005-01-31 16:40:44.000-0600

Everything contained inside a bracket pair prefixed by a $ (like $[this]) is considered as an expression and it is evaluated.

So correct me if i'm wrong but a gotoif might be required to do this.

bkw
By: eko1 (eko1) 2005-01-31 17:14:29.000-0600

I think you're missing the point, which is that the : operator is not working as expected. I'm not trying to implement any kind of gotoif logic. All I'm trying to do is to make : return a the proper match.

For example, if I dial 1987654321, I correctly see:

Executing NoOp("SIP/310-a8a6", "1987654321") in new stack

If I dial 011987654321, I see:

Executing NoOp("SIP/310-6c07", "12") in new stack

which is not what I want.
By: Mark Spencer (markster) 2005-01-31 21:38:10.000-0600

Which documentation are you talking about by the way?
By: Clod Patry (junky) 2005-01-31 21:57:26.000-0600

Please past your extensions.conf.
I suspect config issue in here.
By: eko1 (eko1) 2005-02-01 08:43:23.000-0600

The documentation I'm talking about is in asterisk/doc/README.variables under the OPERATORS section.

Why would it be a config issue? Has anyone tried to reproduce my results? I would be very interested to see the results.
By: Mark Spencer (markster) 2005-02-01 21:55:41.000-0600

Although I did not write the expression code it is clear that this is the programmer's intended (but unexplained) behavior when there are two subexpressions and the second subexpression matches.  Can you avoid the use of two subexpressions?
By: eko1 (eko1) 2005-02-02 08:49:48.000-0600

Who wrote the expression code? We really ought to hear what he/she intended. I can avoid using two subexpressions, which means more lines in extensions.conf. Bummer...
By: Mark Spencer (markster) 2005-02-02 10:57:43.000-0600

The code used appears to be from the public domain "expr.y" available, for example at:

http://www.pell.portland.or.us/~orc/Code/bsd/bsd-current/expr/expr.y

which also contains the same behavior.  I will attempt to ask the "laregly rewritten by JT. Conkolin" contact.
By: Mark Spencer (markster) 2005-02-02 11:03:14.000-0600

Nevermind, I was able to find the description which is as follows:

expr1 : expr2
            The “” operator matches expr1 against expr2, which must be a
            regular expression.  The regular expression is anchored to the
            beginning of  the string with an implicit “^”.

            If the match succeeds and the pattern contains at least one reg-
            ular expression subexpression “\(...\)”, the string correspond-
            ing to “\1” is returned; otherwise the matching operator returns
            the number of characters matched.  If the match fails and the
            pattern contains a regular expression subexpression the null
            string is returned; otherwise 0.

Closer inspection does show that the same text appears in README.variables (somehow I missed it on first read) and thus it is behaving as described and is thus not a bug.
By: Mark Spencer (markster) 2005-02-02 11:04:24.000-0600

(although for completion sake, i should say that having a real regex handliner might not be such a bad thing as another application)