It might help everyone to think about regex's this way: Every repeating pattern (that is, with a *, +, or ?) is "elastic". WHich means that it will gobble up as much as possible, leaving the remainder of the string for the rest of the pattern to attempt to match. If the match occurs, fine. But if you hit a point where things no longer match, the elastic "contracts" and matches less and less in attempt to get the rest of the pattern to match. This is the backup feature. So when you have "\s*" it first gobbles up all the spaces - but if the [^0] can't match, then the spaces contract (up to "zero spaces" because you used '*') and then the [^0] matches the space that was surrendered by the "contraction" of the elastic \s* part of the pattern.
Hopefully, that helps clarify :-) On Nov 24, 2010, at 12:47 PM, no-re...@cfengine.com wrote: > Forum: Cfengine Help > Subject: Re: replace_patterns bug? > Author: babudro > Link to topic: https://cfengine.com/forum/read.php?3,19347,19384#msg-19384 > > For prosperity: The flaw in my regex judgement was following my logic in a > sequential left-to-right fashion, assuming that "\s*" would always match an > available space rather than yielding to allow the subsequent [^($x)] to match > the space. Michael Potter gave a good and concise answer (in a fork of this > topic) when he said (quoting from memory) that regex will always try to find > a match. So by allowing the "\s*" to match zero spaces it permitted the > regex to match where otherwise it would not match. > > _______________________________________________ > Help-cfengine mailing list > Help-cfengine@cfengine.org > https://cfengine.org/mailman/listinfo/help-cfengine _______________________________________________ Help-cfengine mailing list Help-cfengine@cfengine.org https://cfengine.org/mailman/listinfo/help-cfengine
