While I think we alread settle fort he other alternative, there is one point I'D like to take (as it may be important for future discussions): > > One thing though, that is on my feature list is that I would like to > use a > > more standard parser, that means one that can becreated with lex and > Bison. > > While the hand-crafted parser is fine, it always is more work to > extend and > > enhance it. As the parser is no critical component, I'd prefer to use > the > > simpler approach. However, I need to check if I can find a suitable > grammar > > for this proposal. This also works on the assumption. > > I don't see this as a problem. It's work to define a parser, but I > don't > think that the current grammer is significantly harder to put into a > lex/bison parser than any other (the exception being the implicit > scoping > rules)
A problem from the grammer PoV is that a traditional action line has no structure at all. It is anything from the first non-whitespace after the filter to the end of line. So here we need LF as a delimiter, while in all other cases, NL should be consider as whitespace and be discarded. You really can't specify this with a decent contextfree grammar, but Flex's substates most probably provide sufficient power to cover these "two languages in one" approach. But as I said ... this seem no longer be relevant to the current discussion, as we will probably stick with the current config system and its parser. Rainer _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com
