On Mon, Oct 21, 2013 at 12:32 PM, David Lang <[email protected]> wrote: > On Mon, 21 Oct 2013, Rainer Gerhards wrote: > > what I've tried among others: >>>>>>>> >>>>>>>> if $/zz % 3 == 0 or $/zz % 3 == 1 then { >>>>>>>> set $/zz = $/zz + 1; >>>>>>>> action(...) >>>>>>>> } else { >>>>>>>> set $/zz = 0; >>>>>>>> action(...) >>>>>>>> } >>>>>>>> >>>>>>>> Could you please explain how is it supposed to work? >>>>>>>> >>>>>>>> >>>>>>>> It's supposed to work just as you describe it. But indeed, it >>>>>>>> >>>>>>> doesn't do >>>>>>> so, I can reproduce the problem. Looks like a regression. Thanks for >>>>>>> reporting, will now look into it. >>>>>>> >>>>>>> >>>>>>> OK, looks like I stumbled into my own trap. In script, you access >>>>>>> >>>>>> properties via $<propname>. Global variables have the name $/zz (with >>>>>> zz >>>>>> being the real name). So to access them, you need to access $$/zz. >>>>>> >>>>>> I think I got confused about this some time ago, and the doc is also >>>>>> not >>>>>> correct or at least inconsistent. I now need to work my way through >>>>>> that >>>>>> mess. Just thought I give you some explanation. >>>>>> >>>>>> >>>>>> Ouch, this is going to get ugly since $$var actually ends up giving >>>>> you a >>>>> reference to $var not it's value, I believe from prior discussions that >>>>> the >>>>> normal variables are $property of $!var!var, >>>>> >>>>> >>>> >>>> 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 ;) Rainer _______________________________________________ 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.
