No, braces (blocks) are just to form a single statement out of multiple. If you add a single one (if), you do not need them.
Grammar: if stmt else stmt Rainer Sent from phone, thus brief. Am 01.12.2016 23:22 schrieb "David Lang" <[email protected]>: > Ok, my mistake was thinking each else needed it's own {}, which results in > a lot of closing } at the end of the sequence. > > David Lang > > On Thu, 1 Dec 2016, Rainer Gerhards wrote: > > Just on elseif... We have it, it's just a question of writing style. Insert >> a space and you get: >> >> If expr >> Else if expr >> Else if expr >> Else >> >> So there is no need for a special statement. Note that for the very same >> reason, elseif does not exist in many programming languages. C, for >> example, does not have it. >> >> Rainer >> >> Sent from phone, thus brief. >> >> Am 01.12.2016 23:05 schrieb "David Lang" <[email protected]>: >> >> On Thu, 1 Dec 2016, [email protected] wrote: >>> >>> Hi >>> >>>> >>>> Is there any way to dynamically invoke a ruleset? eg: call $var >>>> (I'm trying to avoid having +200 if statements... >>>> >>>> >>> sigh, this is getting a wee bit frustrating, you keep saying "it hurts >>> when I do X", we say "that doesn't work well, do Y" and you come back a >>> day >>> or so later saying "but it really huts when I do X"... (it doesn't help >>> when we ask you to provide information and you instead spend hours trying >>> other things) >>> >>> some tools require you to split the logs up early and have completely >>> seprate processing of each log type in order to scale (mostly because >>> their >>> speed in any one thread is so horrible), rsyslog is architected for very >>> high performance when you keep everything together and only split it up >>> in >>> limited cases. >>> >>> now that I have expressed my frustration, you are finding bugs, helping >>> to >>> fix them, and raising some good questions along the way. Just understand >>> why once in a while our answers seem a bit curt. >>> >>> >>> >>> while I can see the use cases for "call $.var", what would you do if you >>> call a ruleset that doesn't exist? you would first have to do 'if $.var >>> == >>> [array of legal values] then' to be safe. >>> >>> You don't like having lots of >>> >>> if <condition> then { >>> stuff >>> stop >>> } >>> >>> there are several approaches to doing this >>> >>> 1. just a bunch of if statements >>> >>> performance cost of doing a bunch of if tests >>> easy to include additional tests from a directory of files >>> >>> 2. if then else >>> >>> same number of tests >>> no need for stop >>> lots of trailing brackets >>> not include friendly >>> >>> if <condition> then { >>> } else { >>> if <condition> then { >>> } >>> } >>> >>> 3. add elsif >>> >>> same number of tests >>> no need for stop >>> no odd trailing brackets >>> more include friendly thatn #2, but not as much as #1 >>> >>> if <condition> then { >>> } >>> elseif <condition> then { >>> } >>> >>> 4. switch statement >>> >>> no faster than the above, but with potential for config optimization >>> cannot do more complex conditions >>> similar include impact as #3 >>> >>> switch $.var { >>> case "value" {} >>> case "value" {} >>> } >>> >>> 5. variable call statements >>> >>> what to do if called ruleset doesn't exist? >>> include friendly if you don't have to have a guard test first >>> >>> call $.var >>> >>> >>> 6. function lookup tables >>> >>> solves the 'unknown thing to call' proclem >>> requires compiling config snippets at table load time >>> cannot do complex tests >>> table lookup could be extended to expand the sparse-array concept to >>> string (solving the common 'startswith' type of test) >>> >>> exec table_lookup(functions,"$.var") >>> >>> >>> >>> now, looking at them in terms of complexity to implement >>> >>> #1 and #2 exist today >>> >>> #3 (elsif) seems like a fairly simple change to support >>> >>> #4 (switch) is a bit more complex >>> >>> #5 (call var) sounds like it's easy to implement >>> >>> #6 (function pointers) is significantly more work >>> >>> >>> Personal opinion >>> >>> I'd like to see us add elsif (#3), it significantly cleans up long >>> if-then-else cascades. >>> >>> I think that with elsif, the need for switch (#4) is low, and the >>> restrictions of it only doing simple equivalence tests (no startswith, >>> contains, etc) really limit it's use >>> >>> call var (#5) seems easy to implement, but I really don't like opening up >>> the problem of calling a non-existant ruleset. We could have it silently >>> do >>> nothing, but that gets really messy and I am already cringing at the >>> troubleshooting exhanges we will have to help people figure out what >>> is/isn't happeing. >>> >>> >>> function pointers are by far the most complicated, and since they include >>> ruleset parsing after startup, they have the potential to be really ugly >>> to >>> implement. On the other hand, they are also by far the most powerful. If >>> we >>> could do things like limiting the functions so that they can't do any of >>> the startup-type things[1] and only include statements that are normally >>> executed for each log type, this would also give us a back-door way of >>> providing the dynamic configuration that many people have been asking >>> for. >>> >>> Internally, this could be implemented by creating rulesets and calling >>> them based on the result of the lookup. >>> >>> [1] no changes to global() or main() >>> no loading modules. >>> probably no creating inputs >>> possibly allow template creation >>> just set and action() calls >>> >>> David Lang >>> _______________________________________________ >>> rsyslog mailing list >>> http://lists.adiscon.net/mailman/listinfo/rsyslog >>> http://www.rsyslog.com/professional-services/ >>> What's up with rsyslog? Follow https://twitter.com/rgerhards >>> NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad >>> of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you >>> DON'T LIKE THAT. >>> >>> _______________________________________________ >> rsyslog mailing list >> http://lists.adiscon.net/mailman/listinfo/rsyslog >> http://www.rsyslog.com/professional-services/ >> What's up with rsyslog? Follow https://twitter.com/rgerhards >> NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad >> of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you >> DON'T LIKE THAT. >> >> _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com/professional-services/ > What's up with rsyslog? Follow https://twitter.com/rgerhards > NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad > of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you > DON'T LIKE THAT. > _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com/professional-services/ What's up with rsyslog? Follow https://twitter.com/rgerhards NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.
