Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
[dev.icinga.com #2291] unknown macros are not replaced, and misleading to single dollar signs #855
This issue has been migrated from Redmine: https://dev.icinga.com/issues/2291
Created by mfriedrich on 2012-01-29 00:21:22 +00:00
if you are using macros which are not valid in the current situation, such as using $CONTACTEMAIL$ within a check command, or a service only macro while executing a host check/notification, this will put the macro as is on the shell.
this is then being interpreted as $CONTACTEMAIL (empty) and $ ... and then confusing the user that there was only a dollar sign as macro replacement.
2012-08-22 17:46:32 +00:00 by mfriedrich 02341c6
2012-10-08 13:28:14 +00:00 by mfriedrich d5f9efd
Updated by mfriedrich on 2012-01-29 00:39:04 +00:00
one major disadvantage removing the output - strings containing two dollar signs could be accidently interpreted as macro, i.e. passwords. so this must be evaluated if to be resolved differently, or just updating the documentation on possible errors.
another reason for removing it might be the case that all dollar signs need to be escaped by a second one, i.e. "$$foo$$bar" becomes "$foo$bar" afterwards.
Updated by mfriedrich on 2012-08-22 17:37:09 +00:00
Updated by mfriedrich on 2012-08-22 17:38:10 +00:00
Updated by mfriedrich on 2012-08-22 17:42:38 +00:00
this is a behavioural change, which should be marked in CHANGES section. people wanting the old behavior can revert that by setting
where the macro outputbuffer is kept as is. the default case will be to warn the user on unkbown macros.
that can be
it possibly not work with the shell tricks for passwords, such as
the correct way of defining that one will be
in order to let the core know that there's actually a valid dolar sign. that method is described in the docs, but i believe people have probably circumvented that in various ways, so prepare for the clusterfuck either way.
but, as a matter of fact, leaving that on the shell for interpreting $foo and erroring out on $ this should be fixed either way.