Hi, @ekopalypse, @sagar-kurapati, @alan-kilborn and All,
@ekopalypse, you’re perfectly right about it ! I’m probably going to add a remark in my previous post !
Indeed, if I move the caret to a line containing a MD5 signature, without the restrictive condition that it must also contain the string POST/items/update-batch, my regex wrongly matches it :-((
The problem is that, after moving caret to any position, the regex engine thinks that this location is the very start of the text. It’s a general drawback of the powerful \G behavior !
Normally, the regex engine always tries, first, the first alternative of regex C, because of the (?-s) modifier and because of line-breaks in text. Indeed, the second alternative is never tried, first, as possible matches cannot be contiguous
So the 1st part matches, for instance, the string OST/items/update-batch4311bbbeca82649427b192c7b868133c. Then the 2nd alternative \G.+?\K[[:xdigit:]]{32} matches the contiguous area, made of the smallest range of any standard char till an other MD5 signature and so on … till the end of current scanned line
Then, because of the line-break chars, the next match cannot be contiguous, implying, necessarily, that the next match will be satisfied by the first alternative, only !
A solution would be to :
Firstly mark all the lines containing the string OST/items/update-batch with a special symbol, ending each line
Secondly, search for any MD5 signature, ONLY IF current line ends with that special symbol
Thirdly delete this special symbol, as well
But, I haven’t found out a fair regex to suppress this drawback, yet !
To conclude, I think that the only sensible solution is to move the caret to the very beginning of file, which does not match, most of the time, the regex pattern located after the \G syntax ;-))
Best Regards,
guy038
