Hello Sebb, I already implemented it, I can remove it if you dislike it. I implemented it to answer initial requirement mentionned here:
- https://issues.apache.org/bugzilla/show_bug.cgi?id=54176 - http://stackoverflow.com/questions/13472646/how-to-escape-regular-expression-characters-from-variable-in-jmeter Regarding ORO , I agree with you but what about compatibility ? it would be an option of regexp components ? Regards Philippe On Thu, Nov 22, 2012 at 1:41 PM, sebb <[email protected]> wrote: > On 22 November 2012 12:07, <[email protected]> wrote: > > https://issues.apache.org/bugzilla/show_bug.cgi?id=54189 > > > > Bug ID: 54189 > > Summary: Add a function to quote ORO regexp meta characters > > Product: JMeter > > Version: 2.8 > > Hardware: All > > OS: All > > Status: NEW > > Severity: enhancement > > Priority: P2 > > Component: Main > > Assignee: [email protected] > > Reporter: [email protected] > > Classification: Unclassified > > > > This function would do the equivalent of \Q \E for ORO Regexp as it does > not > > exist in it. > > Quoting strings won't be trivial. > Also I'm not sure how one would use it in test plans - seems like it > would be very awkward to use. > A better solution might be to implement \Q \E processing, e.g. by > converting the string if it contains \Q and \E. > [This would require the additiional step of first splitting the string > into chunks delimited by \Q and \E] > > However the changes would be a waste of time if we decide to replace > ORO with Java regex processing. > > AIUI ORO was used originally because it was faster than the Java > equivalent; however that was a long time ago. > It's likely that the Java implementation has been improved since then. > There may possibly be some advantages of the ORO implementation, but I > can't think of any off-hand. > > I think we need to look at whether ORO is still needed before trying > to fix any of its omissions. > -- Cordialement. Philippe Mouawad.
