I know that in 7.4.4 it is referenced using straight $!nn for local variables in script and templates then with %$!nn% in legacy. It seems like it might be workable to keep that consistent. $!nn, $/nn and $.nn in script/templates with a legacy support of %$!nn%, %$/nn%, %$.nn%.
That way it is consistent with the expected behavior that people have been using, merely expanding to support a larger spectrum of variables. Unless there is a specific limitation that requires a change of that functionality. -- James -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Rainer Gerhards Sent: Monday, October 21, 2013 7:43 AM To: rsyslog-users Subject: Re: [rsyslog] A solution to action load balancing On Mon, Oct 21, 2013 at 2:38 PM, David Lang <[email protected]> wrote: > > > On Mon, 21 Oct 2013, Rainer Gerhards wrote: > > 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 >> > > hmm, at this point there's a fair bit of documentation, examples, etc > that use %$!nnn% in configs, while it may make things more consistant > to be able to eliminate the $, I'm not sure it's really gaining a lot > if we have to support the old version anyway for backwards compatibility. > > I am concerned about potential future confusion - and all the work required in doc and otherwise when we need to explain that in script you need to use this and in templates you need to use that. I'd like to come back to "in script and template use this". With the "old one" just being supported for legacy, but still working. Rainer > If this had been thought of when $! was first introduced, it may have > been the right way to go from the beginning, but I'm not sure the > benefit is worth the effort. > > > - 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. >> > > while this is a wart, I don't think it's a big one. > > however, I don't know the rsyslog internals well enough, but I don't > think there would be any conflicts if you lost the extra $, so it's > still not ambiguous (although there may be some other reason), but > again, people are already using $$myhostname today, so even if we > could change it, I'm not sure it's worth doing. > > David Lang > > 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:**//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/> >>>> <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://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://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. _______________________________________________ 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.
