hi David,
actually, a subset of these variables has already been implemented in the
2.7.9 version. The currently supported ones are:
%.sec, %.min, %.hour -- seconds, minutes, and hours, represented with two
digits, zero padded on the left
%.hmsstr -- hours, minutes and seconds in HH:MM:SS format
%.mon, %.mday -- month and day of the month (two digits, zero padded on the
left)
%.monstr -- string representation for month as returned by strftime %b
specification (for April 1, %.monstr would be "Apr" on most platforms).
%.mdaystr -- string representation for day of the month, represented with
two digits, space padded on the left (for April 1, %.mdaystr would be " 1").
%.year -- year (four digits)
%.wday -- day of the week (digits from 0 to 6)
%.wdaystr -- string representation for day of the week (as returned by
strftime %a specification, for example Thu).
%.tzname -- name of the timezone as returned by strftime %Z
%.tzoff -- timezone offset as retuned by strftime %z (usually in +/-HHMM
format)
%.tzoff2 -- like %.tzoff, but with a colon between hours and minutes
(+/-HH:MM).
Some variables holding numerals without padding have not been implemented,
but it is quite simple to do the conversion.
For example, the following action
action=lcall %sec %.sec -> ( sub { $_[0] + 0 } )
adds 0 to the value of %.sec variable (seconds) which returns a numeral
without zero padding. This value is then assigned to %sec variable.
Also, values without padding are less frequently used in file names and
timestamps, and more often in actions that execute perl code. However, when
arithmetic operations are applied to zero padded values in Perl, such
values are automatically converted to regular numerals. So IMHO the lack of
variables holding unpadded values is not a big issue.
kind regards,
risto
2016-04-18 21:47 GMT+03:00 David Lang <da...@lang.hm>:
> On Thu, 18 Feb 2016, Risto Vaarandi wrote:
>
>
>> hi all,
>>
>> currently, sec supports couple of builtin action list variables: %s that
>> holds the value of the rule 'desc' field, %t that holds the textual
>> timestamp, and %u that holds seconds since epoch.
>>
>> During recent discussions in the mailing list an idea came up to add
>> support for new builtin action list variables. On one hand, some actions
>> might benefit from specific parts of the timestamp: for example, creating
>> files with 'write' action with YYYY-MM-DD extension, or sending messages
>> to
>> remote syslog servers with 'udpsock' that requires the generation of valid
>> BSD syslog timestamps.
>>
>> Also, in some cases actions would benefit from builtin action list
>> variables that would hold special characters, such as newline and carriage
>> return.
>>
>> During some preliminary code development, I've added support for the
>> following additional builtin variables, and I'd like to ask for user
>> opinions whether this variable set looks OK to you.
>>
>> Firstly, in the alpha code there are variables for some commonly used
>> special characters:
>>
>> %.nl = newline
>> %.cr = carriage return
>> %.tab = tab
>>
>> (It is quite easy to extend this set with all special characters ASCII
>> 0-31
>> by a simple naming convention %.asc<N>, but I am not sure if there is any
>> practical need for this.)
>>
>
> I think we may as well add them in. I know I've run across a few oddities
> and it seems better to add them all than to play wack-a-mole on them over
> time.
>
> As for the other variables, they seem to cover things, but I wish there
> was a good way to not have three versions of everything. But I guess that
> would require having a function to cast them from one class to another :-(
>
> David Lang
>
>
> Then there are variables for raw values returned by perl localtime()
>> function. For instance, if the current time is Monday, February 1,
>> 12:00:01
>> 2016, these variables would be set as:
>>
>> %.secraw = 1
>> %.minraw = 0
>> %.hourraw = 12
>> %.mdayraw = 1
>> %.monraw = 1 (0 corresponds to January)
>> %.yearraw = 116 (offset from 1900)
>> %.wdayraw = 1 (0 corresponds to Sunday)
>>
>> Time-related variables %.sec, %.min, %.hour, %.mday, %.mon, %.year --
>> these
>> variables consist of 2 digits (apart from %.year which has 4 digits) and
>> are zero padded on the left. If the current time is Monday, February 1,
>> 12:00:01 2016, these variables would be set as:
>>
>> %.sec = 01
>> %.min = 00
>> %.hour = 12
>> %.mday = 01
>> %.mon = 02
>> %.year = 2016
>>
>> In addition, there would be few variables with 'str' suffix for string
>> representation of some fields:
>>
>> %.mdaystr = " 1" (date with space padding on the left)
>> %.monstr = "Feb" (string abbreviation for the month, as returned by
>> strftime("%b"))
>> %.wdaystr = "Mon" (string abbreviation for the weekday, as returned by
>> strftime("%a"))
>> %.tzstr = "UTC" (string abbreviation for the timezone, as returned by
>> strftime("%Z"))
>>
>> Since timezone offset would also be handy for generating ISO8601
>> timestamps, there is a variable %.tzoffset which holds the result of
>> strftime("%z") (for example, "+0000" or "-0500"). Nevertheless, since in
>> some cases a colon is required between minutes and hours, there is also
>> %.tzoffset2 variable which supports this format (e.g., "+00:00").
>>
>> When these variables are around, the following actions become easier to
>> implement:
>>
>> # produces a separate log file for each day, for example
>> # /var/log/mylog-2016-02-18
>> write /var/log/mylog-%{.year}-%{.mon}-%{.mday} "received event: $0"
>>
>> # send an event to remote BSD syslog server with daemon.info priority
>> udpsock server:514 <30>%{.monstr} %{.daystr} %{.hour}:%{.min}:%{.sec}
>> myhost test: This is a test
>>
>> Adding support for these variables involves minimal overhead, since %.nl,
>> %.cr and %.tab can be created once when sec starts up (or restart at HUP
>> signal), and time-related variables need updating just once a second.
>>
>> In the Perl documentation, there is a warning about possible portability
>> issues with strftime("%z"), since %z specifier is not part of the ansi c
>> standard, and some windows platforms might not support it. Nevertheless,
>> currently strftime seems the best option for obtaining timezone
>> information
>> without introducing dependencies on perl modules which are not part of the
>> perl core.
>>
>> Any opinions on these variables?
>>
>> kind regards,
>> risto
>>
>>
------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
Simple-evcorr-users mailing list
Simple-evcorr-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
