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.
| [reply] [d/l] [select] |
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 :)
| [reply] [d/l] |
$ 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 | [reply] [d/l] |