mIRC Homepage
Posted By: maroon $bfind.regex N>=2 ^ anchor - 06/11/22 11:06 PM
When N is greater than 1, it doesn't ever find a match when using the ^ anchor:

//bset -t &v 1 abcdef | echo -ag 1 vs 0 vs 0: $bfind(&v,2,bc,foo).regex vs $bfind(&v,2,^bc,foo).regex vs $bfind(&v,2,^.*f,foo).regex
Posted By: Khaled Re: $bfind.regex N>=2 ^ anchor - 13/11/22 09:15 PM
In the case of the last $bfind() in your example, PCRE is interpreting this as: for string "abcdef", search for ^.*f (matching from the beginning of the string), but only return results from position 2 onwards. In this call, the ^*.f will match from position 1 onwards, so PCRE says no match was found.
Posted By: Wims Re: $bfind.regex N>=2 ^ anchor - 13/11/22 10:17 PM
This implementation of $bfind().regex is the report.

I'm the one, among others, who requested regex for binvar and this is not how I wanted it to be implemented

What was expected is that with $bfind(&b,2,/pattern/).regex, the input that mIRC would to pass to pcre is $bvar(&b,2-).

Otherwise, with the current implementation, a bcopy is required to set up a new binvar before calling $bfind(), very, very not handy because

1) I have a large binvar, creating a second one can easily fail
2) I do not want to destroy my current binvar nor i want to save it temporarily (could fail, but I just don't.)
3) I don't want to copy anything

Can you make the implementation make the input string start at the Nth position in the binvar instead of scripter having to do it? There are no good reason a scripter would want the current implementation, because of the way regex works, /g etc.

Thanks
Posted By: Wims Re: $bfind.regex N>=2 ^ anchor - 15/11/22 12:49 PM
Thanks for changing $bfind
© mIRC Discussion Forums