in reply to Re^8: Using pos() inside regexp (no /e)
in thread Using pos() inside regexp

What's the difference? The change does not have any effect on the matching. So it is the same as not working at all. After your matching ends, the set value won't even be preserved. So, for the original question "Can pos() be used inside of matching to change where the \G matches" the answer is "No. The pos does not work during matching. In other words, it does not affect the position where the \G matches". And this should be written in the documentation.
  • Comment on Re^9: Using pos() inside regexp (no /e)

Replies are listed 'Best First'.
Re^10: Using pos() inside regexp (no /e)
by ikegami (Patriarch) on Oct 14, 2010 at 16:24 UTC

    So, for the original question "Can pos() be used inside of matching to change where the \G matches" the answer is "No. The pos does not work during matching.

    \G can only possibly match where you left off. (Not processing part of the input string or processing part of the input string twice makes no sense.) Since \G can't possibly match elsewhere, trying to make it do so would result in a pattern that would never match.

    So no, the answer is "No, it makes no sense".

    The change does not have any effect on the matching. So it is the same as not working at all.

    No, it means you think s/// or \G is broken, not pos(). But s/// and \G aren't broken.

      No, it means you think s/// or \G is broken, not pos(). But s/// and \G aren't broken.

      Are you sure you know what I think? :^) I didn't say anything about "broken". I just say, that the function does not work as documented and propose to change the documentation to avoid the long arguments like this.

      One more time. The perldoc -f pos states 'so assigning to "pos" will change that offset, and so will also influence the "\G" zero-width assertion in regular expressions'. In reality, when pos is used during matching it does not influence the "\G". Which means that the documentation is incorrect. If you believe, that pos does influence the \G during matching, then please provide a proof. If you just don't like the words that I've used to state this, then I don't think it makes sense to argue :)

        Which means that the documentation is incorrect.

        Here is the documentation, how would you change it?

        Returns the offset of where the last "m//g" search left off for the variable in question ($_ is used when the variable is not specified). Note that 0 is a valid match offset. "undef" indicates that the search position is reset (usually due to match failure, but can also be because no match has yet been run on the scalar). "pos" directly accesses the location used by the regexp engine to store the offset, so assigning to "pos" will change that offset, and so will also influence the "\G" zero-width assertion in regular expressions. Because a failed "m//gc" match doesn't reset the offset, the return from "pos" won't change either in this case. See perlre and perlop.
        Consider this with the sentence in bold above
        $ perl -le"$_ = 123456; s/./warn pos; warn q, ,, pos=0;/eg" 0 at -e line 1. 0 at -e line 1. 1 at -e line 1. 0 at -e line 1. 2 at -e line 1. 0 at -e line 1. 3 at -e line 1. 0 at -e line 1. 4 at -e line 1. 0 at -e line 1. 5 at -e line 1. 0 at -e line 1.
        so the engine matches, then evaluates the code, then advances pos, and it doesn't care if your code changed pos in the meantime