OK, after a short break (but not really thought out): it probably is most useful to support $!, $/, $. in script as we all thought. This means that we should support %!nnn% %/nnn% and %.nnn% in string templates as well - so add these in addition to the traditional ones in new code. Unfortunately, it seems not as easy for "true" system properties. I think we must insist on $$myhostname in script.
As I said, it's not really thought out, so comments are welcome. In any case, I think I'll start doing some internal refactoring to get the engine ready for whatever changes will be upcoming. Unfortunately, this probably means I can not look into multiple action instances and automatic round-robin --something that I had really loved to do :-( Rainer On Mon, Oct 21, 2013 at 12:50 PM, Rainer Gerhards <[email protected]>wrote: > On Mon, Oct 21, 2013 at 12:43 PM, David Lang <[email protected]> wrote: > >> On Mon, 21 Oct 2013, Rainer Gerhards wrote: >> >> On Mon, Oct 21, 2013 at 12:32 PM, David Lang <[email protected]> wrote: >>> >>> On Mon, 21 Oct 2013, Rainer Gerhards wrote: >>>> >>>> >>>>>>> That previous discussion was wrong, it is $$!var!var - and it does >>>>>>> not >>>>>>> give >>>>>>> the ref to $var, but it's value. >>>>>>> >>>>>>> >>>>>>> hmm, I had a problem where I was trying to set var2 = $$!var1 and >>>>>> then >>>>>> delete var1 and the result was that once var1 was deleted, var2 had no >>>>>> value, if var1 wasn't deleted, var2 had a value. when I posted about >>>>>> it, >>>>>> I >>>>>> was told to change $$ to $ (I'll have to go back and dig up the e-mail >>>>>> for >>>>>> the exact syntax that I used), and changing to a single $ on the right >>>>>> side >>>>>> caused everything to work properly after var1 was deleted. >>>>>> >>>>>> >>>>> >>>>> yeah, that's a big confusion that I created, sorry for that. If you >>>>> look >>>>> at >>>>> git logs, you'll even see that there are a couple of regression fixes >>>>> undoing what an other one did which than got undone... This is what I >>>>> checked this morning when I remembered that there was something in this >>>>> area recently. I *think* the bottom problem is that I did not fully >>>>> obey >>>>> the $<propname> rule, and after initial review it looks so (and so I >>>>> did >>>>> another regression fix that undoes what the previous one did, and I am >>>>> 98% >>>>> sure it is right this time). Get to understand with what I mean with "I >>>>> need a break and the code propbably some refactoring"? >>>>> >>>>> >>>> Yep, this sounds like something for you to fix tomorrow, or at least >>>> after >>>> you have taken a break to clear your mind. People are just starting to >>>> try >>>> and use this, but once they start using it, changing it will break >>>> configs. >>>> right now the documentation (on rsyslog.com and the ;login article) all >>>> use a single $. so my tendancy would be to make the docs work :-) but if >>>> this can't be done, now is the time to change things, we just need to >>>> make >>>> things consistant between the three variable classes >>>> >>>> >>> >>> consistency depends on how you look at it :-( >>> >>> if we support $/zz for global var and $msg in script (instead of $$/zz), >>> the string templates are inconsistent, because they have $/zz and "msg". >>> The core idea when I wrote the script engine was that $ prefixes >>> properties, so that this goes along with the documented properties. If we >>> change that, we need to use different property names in templates and >>> script :-( >>> >>> but... I think I won't discuss this any further today, bears not fruit in >>> my state of mind ;) >>> >> >> for you to think about tomorrow :-) >> >> you already have >> >> template >> >> %hostname% >> %$myhostname% >> %$!% >> >> and script >> >> $hostname >> $myhostname (instead of $$myhostname) >> $! >> >> > sorry, I haven't been clear (how could I ;)). It depends a bit on the > patch level, but in script it should be (and is in many versions) > > $hostname > $$myhostname > $$! > > so it is consistent. > > All please note that the whole discussion centers around -devel branch > stuff, so for stable nothing yet is problematic. > > >> so while I don't really like the template stuff not matching the >> scripting stuff, it's already inconsistent, and I think it's better to be >> consistent within the scripting than to have some of them be $<what you >> would use in a template> and some consolodating $$ into $ >> >> > right > > >> right now the parser can deal with things with a single $ without any >> ambiguity, you are unlikely to add many more properties, so it's unlikely >> to get significantly worse. > > > not really -- this is the cause for the confusion. The parser does not > properly handle it. If the $myhostname syntax is "supported" other things > are broken - Pavel's initial sample is the indication of this. I would need > to refactor the code to be aware of the syntax inconsistence and handle it > properly. > > Rainer > >> >> >> David Lang >> ______________________________**_________________ >> rsyslog mailing list >> http://lists.adiscon.net/**mailman/listinfo/rsyslog<http://lists.adiscon.net/mailman/listinfo/rsyslog> >> http://www.rsyslog.com/**professional-services/<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.
