That's awesome, Risto .. and you are right indeed .. I switched to RegExp,
and now have $+{_inputsrc} interpolated ..
Just checking:
$+{_inputsrc} is giving the full path of the log filename being processed
.. If I just wanted ONLY the name of the context (which is a substring of
this full path name), is their an equivalent variable for it ?
Thanks again ..
On 16 December 2015 at 12:59, Risto Vaarandi <risto.vaara...@gmail.com>
wrote:
> hi Carlos,
>
> you have guessed right that the problem lies in SubStr pattern type. Since
> one of the design goals behind substring patterns was to make them much
> faster than regular expressions, they don't set match variables because
> maintaining them makes the pattern less efficient. Therefore, in order to
> use the $+{_inputsrc} variable, the substring pattern has to be converted
> to a regular expression.
>
> If the substring pattern does not contain any special characters, it is
> just the matter of setting 'ptype' field from SubStr to RegExp.
> Nevertheless, if the string pattern contains special symbols (like dot or
> question mark), these need masking with backslashes, in order to make them
> match corresponding characters (for example, pattern=192.168.0.1 should
> probably be converted to pattern=192\.168\.0\.1).
>
> Hope this helps,
> risto
>
> 2015-12-16 14:14 GMT+02:00 Carlos Gunners <goond...@gmail.com>:
>
>> Hello Risto,
>>
>> Thanks a million for saving me loads of time and pointing out my wrong
>> assumptions about how _THIS is supposed to work ..
>>
>> One more question:
>>
>> I am trying to send emails via pipe, how do I use the variable within my
>> message string .. ie, what's the best way to quote or escape
>> _FILE_EVENT_$+{_inputsrc}
>> or $+{_inputsrc} within my action to ensure it's value is interpolated
>> ..
>>
>> For example, doing any of the following prints the string as is, instead
>> of printing the value represented:
>> - pipe '%t: %s - $+{_inputsrc}'
>> - /usr/bin/mail -s '%s $+{_inputsrc}' admin@mail.example
>>
>> In the above examples, the values %t and %s are interpolated OK .. but
>> the inputsrc string is being printed as a literal string ..
>>
>> I have to point out that I am using ptype=SubStr .. not Regexp .. Could
>> this be a factor in what variables are available for use ?
>>
>> Thanks again for the comprehensive response .. That has been most useful
>> ..
>>
>> best regards
>>
>> On 15 December 2015 at 20:37, Risto Vaarandi <risto.vaara...@gmail.com>
>> wrote:
>>
>>> ...also, I forgot to mention that if you are using the --intcontexts
>>> command line option and default input file context names (i.e.,
>>> _FILE_EVENT_<filename>), you can refer to the current input file context by
>>> _FILE_EVENT_$+{_inputsrc}.
>>>
>>> hope this helps,
>>> risto
>>>
>>> 2015-12-15 22:18 GMT+02:00 Risto Vaarandi <risto.vaara...@gmail.com>:
>>>
>>>> hi Carlos,
>>>>
>>>> there is no such thing as the current context in action list, since
>>>> during any action list execution many contexts can exist simultaneously.
>>>> Nevertheless, as I can understand from your e-mail, you would like to learn
>>>> what is/are the input file name(s) the matching line(s) came from? If so, I
>>>> would recommend to use the match variable $+{_inputsrc}. For instance, the
>>>> following simple rule echos each non-empty line to standard output with the
>>>> input file name:
>>>>
>>>> type=single
>>>> ptype=regexp
>>>> pattern=.
>>>> desc=test
>>>> action=write - Input line $0 came from file $+{_inputsrc}
>>>>
>>>> As for the _THIS context name, it is entirely meaningful, but it is
>>>> designed for a different purpose and has been explained in the beginning of
>>>> the "INTERNAL EVENTS AND CONTEXTS" section. _THIS is a special dynamic
>>>> alias name which exists *only* in the action-on-expire list of the context
>>>> and points to the context itself.
>>>>
>>>> In order to understand why this alias name is useful, lets look into
>>>> the following action:
>>>>
>>>> create TEST 60 (report TEST /bin/mail root@localhost)
>>>>
>>>> This action creates a context with a name TEST which exists for 60
>>>> seconds, and when the lifetime of TEST expires, the action "report TEST
>>>> /bin/mail root@localhost" is triggered (in other words, all events
>>>> saved into the context TEST are mailed to root@localhost).
>>>>
>>>> What would happen if the following actions are executed during the
>>>> lifetime of TEST?
>>>>
>>>> add TEST event1 (string "event1" is saved to event store of TEST)
>>>>
>>>> alias TEST ALIAS (an alias name ALIAS is created for context TEST)
>>>>
>>>> add ALIAS event2 (string "event2" is saved to event store of the
>>>> context which has now two names TEST and ALIAS)
>>>>
>>>> unalias TEST (alias name TEST is dropped, and the above context can
>>>> now only be referenced by name ALIAS)
>>>>
>>>> When the above context expires (originally created with the name TEST
>>>> and now having the name ALIAS), the action-on-expire "report TEST /bin/mail
>>>> root@localhost" will fail, since the context name TEST no longer
>>>> exists. However, when the context would have been created with the
>>>> following action
>>>>
>>>> create TEST 60 (report _THIS /bin/mail root@localhost)
>>>>
>>>> strings "event1" and "event2" would have been mailed to root@localhost,
>>>> since _THIS is a dynamic alias name which points to the context also having
>>>> another name ALIAS.
>>>>
>>>> I hope I was able to answer (at least partially) your original
>>>> question, and also explain the nature of the _THIS alias in a bit more
>>>> detailed way.
>>>>
>>>> kind regards,
>>>> risto
>>>>
>>>>
>>>>
>>>> 2015-12-15 21:10 GMT+02:00 Carlos Gunners <goond...@gmail.com>:
>>>>
>>>>> Hi,
>>>>>
>>>>> I am using several input= switches (with contexts) in a single sec
>>>>> rule to monitor several log files for exactly the same error string ..
>>>>>
>>>>> Now, given each logfile has a different context, I assumed it was
>>>>> straight-forward to grab this in action (or alias) and use it .. But I
>>>>> have
>>>>> spent hours trying to figure out how to just access the name of the
>>>>> current
>>>>> context in an action
>>>>>
>>>>> The docs I have read suggest that the current context is accessible as
>>>>> _THIS .. but this does not seem to be the case .. because:
>>>>>
>>>>> * I have tried to apply copy, assign, alias and report to this _THIS
>>>>> variable and constantly get "Context '_THIS' does not exist"
>>>>> (I am running with --debug=6 --intevents --intcontexts --log=/tmp/blah)
>>>>>
>>>>> * If I send USR1 to sec, the generated dump file shows that the sec is
>>>>> reading the input files and assigning appropriate contexts to them
>>>>>
>>>>> I simply just want to extract the name of the context without knowing
>>>>> exactly what it is .. since it could be one of 10 different values.
>>>>>
>>>>> I suspect I am missing something obvious here .. would really
>>>>> appreciate some help or suggestions
>>>>>
>>>>> thanks in advance ..
>>>>>
>>>>> regards
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>>
>>>>> _______________________________________________
>>>>> 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
