[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