//g in a scalar context finds the next match, starting where the last such match against $sb left off. See pos. I doubt that is what you wanted to do there.

I think what you have is a bug in 5.005 that was fixed in 5.6 and that your new code should work on both versions while your old code is "broken" but 5.005 doesn't notice. Part of this has to be a guess because exactly how you are using that line of code isn't completely clear.

Tye; Thanks for your reply, however, I think that the intended application here is:
List context... e.g my documentation says:

 In list context, it returns a list of the substrings matched by 
any capturing parentheses in the regular expression.  If there are 
no parentheses, it returns a list of all the matched 
strings, as if there were parentheses around the whole pattern.
[download]

This particular line of code  if ($sb =~ /<$fi>\s*(.*?)\s*<\/$fi>/is) { is attempting to capture all the substrings that are taged by string  <$fi>...</$fi>

It is highly possible that I am missing something, but if this is the intended case, do you still think that there is a bug in the application that was tolerated in 5.005 but not in 5.6.0

If the intent was to capture all of the matches, then you'd have to 1) capture them, which would involve, 2) using that construct in a list context.

As it is used, it is in a scalar (Boolean) context which means that whether there is one match or 20 doesn't make a difference and so the /g modifier doesn't add any value. That is why the /g modifier in a scalar context does something different. It just returns the next match.

Now if you replace if with while, then the /g would make sense as a way to have the body of the while loop deal with (the text captured by the parens) one match at a time.

If you have more questions on this, please at least include more code. (:

        - tye (but my friends call me "Tye")