> > I still think it should, because otherwise the "^(a)?b\1$" can never be > > used, and this expression will become "^((a)?)b\1$" if more than one > > character is needed. > > Is that a real concern? I mean that in the sense of whether you have an > actual application requiring that some multi-character bracketing string > either does or doesn't appear on both ends of a thing, and typing another > set of parens is a burden. Both parts of that seem strained. No, it isn't. Even because there is some way to implement this, as Barry and you have shown, and because *I* know it doesn't work as I'd expect. :-)) Indeed, I've found it while implementing another feature which in my opinion is really useful, and can't be easily achieved. But that's something for another thread, another day. [...] > ? Your example is hiding in there, on the "third iteration of the outer > loop". The official POSIX interpretation was that it should match just the > first 6 characters, and not the trailing #, > > because in a third iteration of the outer subexpression, . would match > nothing (as distinct from matching a null string) and hence \2 would > match nothing. [...] Thanks for giving me a strong and detailed reason. I understand that small issues can end up in endless discussions and different implementations. I'm happy that the POSIX people thought about that before me <2.0 wink>. > > Could you please reject the patch at SF? > > I'm not sure which one you mean, so on your authority I'm going to reject > all patches at SF. Whew! This makes our job much easier <wink>. That's good! You'll take back the time you wasted with me. ;-)) -- Gustavo Niemeyer [ 2AAC 7928 0FBF 0299 5EB5 60E2 2253 B29A 6664 3A0C ]
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4