I suspect there may be no alternative variable for the current context,
given your initial detailed explanation ..

Parsing $+{_inputsrc} with common shell commands (awk, cut, etc) and
extracting the field required is trivial .. but how to use shell commands
within sec is somewhat confusing ..

any suggestions .. or examples ..

thanks again

On 16 December 2015 at 14:55, Carlos Gunners <goond...@gmail.com> wrote:

> 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

Reply via email to