[sr-dev] dialplan and empty repl_exp

Richard Fuchs rfuchs at sipwise.com
Tue May 8 00:38:12 CEST 2012


On 05/07/12 16:47, Daniel-Constantin Mierla wrote:
> Hello,
>
> On 5/7/12 8:57 PM, Juha Heinanen wrote:
>> Richard Fuchs writes:
>>
>>> I know that, but that doesn't answer my question. :) Regex substitutions
>>> work the same everywhere, s/(.)/\1/ in sed or Perl for example leaves
>>> the string unchanged. Why is the dialplan module different?
>> are you sure that (.) does the trick? i have used (.*) and that works ok.
> indeed the .* is at least the posix standard way to match everything,
> '.' being for matching one single character.

Yes, with the point here being that a PCRE substitution commonly only 
works on the part of the string that the RE matched. Other parts would 
be left untouched. For example, you could use an RE of "^." (or even 
just ".") and a replacement string of nothing to simply strip away the 
first character.

tabasco:~# echo foobar | sed -e 's/^.//'
oobar
tabasco:~#

> I would consider a bug if there is no way to remove the full value
> (i.e., set the result to empty string), like no change will happen with:
> subst="(.*)"
> repl=""

This would still be valid and would do the same thing.

> Personally, I would not mind an update to get to a more common
> behaviour, if it will be properly documented and referenced to other
> well established languages/tutorials. So far the term was 'perl-like
> substitutions' not 'perl substitutions' more for syntax/idea.

Of course, but like I said, so far all Perl-like RE engines I've come 
across (PHP is another example with its preg_replace(), Python has 
re.sub(), etc) work by only replacing the matched part of the string. 
It's a search-and-replace operation, not a 
break-down-and-create-new-string operation.

> Also, we
> have our specific behaviour, the repl expression can include cfg
> variables (e.g., $avp(...), $var(...), ...) that are expanded when
> building the result.
>
> However, I think it is too late for 3.3.0, because it will introduce lot
> of changes, perhaps many in the behaviour as well, and we are already 2
> weeks in the testing phase.

Understood. I've originally thought it was simply a bug because it 
didn't do what I'd expected, but I guess it's an old design decision. 
Thanks for clarification. Maybe for 3.4 then :)

BR
Richard



More information about the sr-dev mailing list