Hi Yclept.
> I want to illustrate how augeas' limitations make it difficult or impossible > to match even the simplest statements. Its never impossible to match what you want. Though it does get very complicated and difficult to match anything you can think of at the same time. I happily agree, that for some scenarios, Augeas does have its fair share of traps and corner cases. Though looking at your examples again, some use cases can be ignored safely, I guess. For example, to allow optionally superfluous spaces really complicates the regular expressions without gaining much. > For those comfortable with the generic modules, here are the equivalences: (…) Note that you have still made your own definitions. Sep.space is not defined as 'del /=/ "="', since it allows for optional spaces on either side. That's the reason why my first proposed match statement was ambiguous. And that's the very reason why '[ key Rx.word . Sep.space? . Sep.equal . Sep.space? ]' is ambiguous, too. I avoided the ambiguity by dismissing an additional white space in front of the comment. The flaw then became, that the (optional) value and (optional) comment must not be separated by white space anymore. I do admit, that this common case is difficult to address with a simple regular expression, that I cannot come up with. Luckily, I don't have to, because the Simplevar module exists and demonstrates how one might solve that problem. It actually takes advantage of what you criticized before: It creates an additional empty subtree in order to avoid ambiguity. Best regards, Xavier. From: Yclept Nemo [mailto:[email protected]] Sent: Monday, November 02, 2015 5:56 PM To: Mol, Xavier (SCC) Cc: augeas-devel Subject: Re: [augeas-devel] Matching key/value statement Hi, > Yet I feel like you actually wanted to point out something different with > your mail from the start I want to illustrate how augeas' limitations make it difficult or impossible to match even the simplest statements. For those comfortable with the generic modules, here are the equivalences: let spaces = /[ \t]+/ " " = Sep.space let spaces_none = del /[ \t]*/ "" = Sep.opt_space let equal = del /=/ "=" = Sep.equal > let match = [ Util.del_opt_ws "" . key Rx.word . Sep.space_equal . (store > Rx.word)? . Util.comment_noindent? ] Now these are the conditions violated in each case by your suggestion: n | let record = [ key Rx.word . Sep.space? . Sep.equal . Sep.space? ] n | | [ key Rx.word . Sep.space? . Sep.equal . Sep.space? . comment ] n | | [ key Rx.word . Sep.space? . Sep.equal . Sep.space? . value ] y | | [ key Rx.word . Sep.space? . Sep.equal . Sep.space? . value . spaces? . comment ] y | let record = [ key Rx.word . Sep.space? . Sep.equal . Sep.opt_space ] n | | [ key Rx.word . Sep.space? . Sep.equal . Sep.space? . comment ] y | | [ key Rx.word . Sep.space? . Sep.equal . Sep.space? . value . Sep.opt_space ] y | | [ key Rx.word . Sep.space? . Sep.equal . Sep.space? . value . Sep.space? . comment ] That said, I have already worked out a possible and complicated solution for each of the above ambiguous cases. Sincerely,
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ augeas-devel mailing list [email protected] https://www.redhat.com/mailman/listinfo/augeas-devel
