> Hi Risto, > > Thank you very much for your suggestions and explanation. > Must agree with your arguments that introducing "continue" field option > support into "Suppress" rule will introduce some confusions. > I have never thought that this type of suppression logic can be achieved > by "Jump" rule. Thanks for bringing it up. >
hi Dusan, it is my bad that I forgot to mention this opportunity in the man page, but I'll incorporate it in the documentation for the next version. Also, this topic would actually make a good FAQ entry. > Thanks for this great piece of software and I really appreciate your > support and help. > I am happy that you like sec and have found it useful :-) kind regards, risto > Dusan > > ------------------------------ > *Od:* Risto Vaarandi <risto.vaara...@gmail.com> > *Odoslané:* štvrtok, 11. októbra 2018 22:47 > *Komu:* dusan.so...@hotmail.sk > *Kópia:* simple-evcorr-users@lists.sourceforge.net > *Predmet:* Re: [Simple-evcorr-users] Suppress rule and continue filed > support > > > Hello SEC Users, > > > > > hi Dusan, > > Base on SEC documentation *Suppress* rules doesn’t support “continue” > field like other rules. > > My understanding is that if suppress rule match event the search for > matching rules ends in the *current* configuration file. > > > That's correct, the Suppress rule works indeed within the scope of the > current rule file only. > > > > Let’s consider this simple example with two config files: > > > > Config file: 01.sec > > > > type=Suppress > > ptype=RegExp > > pattern=foo > > desc=$0 > > > > Config file: 02.sec > > > > type=Single > > ptype=RegExp > > pattern=foo > > continue=EndMatch > > desc=$0 > > action=write - foo matched > > > > If you launch sec: > > sec -conf=./*.sec -input=- > > > > And put “foo” in the input: > > * In first configuration file suppression rule match "foo" and switch to > next configuration file. > > * In second configuration file Single rule match "foo" and action is > taken. > > > > I think it can be beneficial if "Suppress" rule will support *continue* > filed so I can tell that I don't want to continue to find match in *all* > next configuration files. > > > That approach has one downside -- it would introduce confusion among > users, since some values for "continue" like "TakeNext" and "GoTo" imply > that the matching process will not stop but rather proceed from another > rule. In sec code, it is of course possible to either ignore such values or > report an error, but from the design perspective it isn't the best > solution. I would rather favor the creation of a separate rule type (e.g., > Stop instead of Suppress) -- but if you consider already existing rule > types, the Jump rule is actually meeting your needs. > > The whole purpose of this rule is to actually control the rule processing > flow, and you can utilize it for continuing processing in another rule > file. When you omit the "cfset" field from Jump, the Jump rule can also be > used for controlling the rule processing order within a single rule file, > provided that the "continue" field has been set to "GoTo". Also, without > "cfset" field and "continue" omitted (or set to "DontCont"), Jump is > identical to Suppress. Both of those special cases have been described in > the documentation for the Jump rule. > > However, if you omit "cfset" and set "continue" to "EndMatch", the Jump > rule will do exactly what you want. For example, the following rule will > end processing for all events which contain the substring "test": > > type=Jump > ptype=substr > pattern=test > continue=endmatch > > I acknowledge that the documentation should also explicitly describe this > particular case, in order to make it obvious to the reader. > > > > > I know that I can achieve this by replacing "Suppress" rule in 01.sec > configuration file by "Single" rule and do not take any action and define > continue=EndMatch. > > > One of the drawbacks of this approach is the need to set the "action" > field to "none", while it would be more convenient not to define that field > at all. However, with the Jump rule you would not have this issue. Also, > since Jump is specifically designed for exercising control over rule > processing (and Suppress rule is actually a special case of Jump), the use > of Jump would be quite appropriate here. > > hope that helps, > risto > > > > Thanks, > Dusan > > _______________________________________________ > Simple-evcorr-users mailing list > Simple-evcorr-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users > >
_______________________________________________ Simple-evcorr-users mailing list Simple-evcorr-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
