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" <da...@lang.hm>:

> 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" <da...@lang.hm>:
>>
>> On Thu, 1 Dec 2016, mosto...@gmail.com 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.

Reply via email to