Good point. My original example code didn't handle that case correctly in part because it started out as an example of using a regular expression to match record terminators and in part because I had not fully considered the effect of //z on greedy matches until I replied to theorbtwo's node.

We already have a separate "continue where it left off last time" feature for regular expressions: //g in a scalar context and pos(). So my example is easy to fix by dropping /z once I've found end-of-stream. I'll update it shortly to reflect this.

Note that my example fetches pos() in order to strip stuff from the front of the buffer, therefore each match is performed with pos()=0. If, for example, you were instead matching record terminators, then you would instead fetch pos() in order to restore it before the next match (since the sysread updates the contents of the buffer which also resets its pos).

Thanks,
                - tye

But how does the regex engine know that that search sans /z is supposed to be the finishing search of the previous series of /z searches, as opposed to an entirely new pattern to be applied? What I'm talking about is analogous to using /gc and then finally only /c to conclude the series of matches. If there was no /g, the (lack of) presence of /c alone would be ambiguous.

Makeshifts last the longest.

Because

We already have a separate "continue where it left off last time" feature for regular expressions: //g in a scalar context and pos().

and that is what we'd use. //z would not imply "start where you left off last time". There is no reason for it to because we already have //g and pos(). Why do you think I've been using //g and messing with pos() in my example?

//z would only tell the regex engine to fail [and set pos()] if it looks at the end of the string/buffer. It wouldn't tell it to start where it left off and it wouldn't keep track of where it left off other than by setting pos().

                - tye