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.
