Re: [Nagios-devel] Undefined custom macros remain unparsed
Posted: Wed Apr 08, 2009 9:04 pm
matthias eble wrote:
> Hi List,
>
> currently Nagios doesn't touch macro strings ($...$) if they are
> undefined. Neither custom nor for default macros get interpreted so that
> the original $...$ string remains the same.
>
> To me $_HOSTUNDEFINEDMACRO$ should evaluate to an empty string rather
> than being left untouched. Especially when used in commands, the
> $_HOSTUNDEFINEDMACRO part gets interpreted by the shell (usually empty)
> and the trailing $ is displayed plainly.
>
> Following patch is made against 3.0.5 but applies cleanly to latest git
> snapshot from git.nagiosprojects.org. It changes the behavior for custom
> macros.
>
> Does anyone see any reasons why this should not be changed?
>
It makes it impossible to use shell variables in commands.
Imagine something like this:
echo "hoopla" > $HOME/$HOSTADDRESS$
as a really, really stupid notification script (or whatever).
Will "$HOME/$" get removed, leaving "HOSTADDRESS$" just because
it's not a valid macro?
If you parse all valid macros first and then remove the remaining
ones, how would you handle
echo "hoopla" > $TMPROOT/.private/$USER/$HOSTADDRESS$
(which is a rather common layout to create user-private temporary
directories on security anal systems). After $HOSTADDRESS$ is
removed, would you then strip "$TMPROOT/.private/$" from the
command?
You could ofcourse getenv() the string after the dollar sign, but
then you'll (someday) run headlong into this:
echo "hoopla" > $TMPROOT/.private/${HOME##*/}/$HOSTADDRESS$
and then you'll spend the rest of your life extending Nagios'
shell-variable quoting code to match that of whatever shell you
happen to be using (not really, but you get the idea I'm sure).
A better way of achieving what you want is to extend the macro
syntax so that
$?_RANDOMCUSTOMVARIABLE$
expands to nothing if _RANDOMCUSTOMVARIABLE can't be located.
--
Andreas Ericsson [email protected]
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]
> Hi List,
>
> currently Nagios doesn't touch macro strings ($...$) if they are
> undefined. Neither custom nor for default macros get interpreted so that
> the original $...$ string remains the same.
>
> To me $_HOSTUNDEFINEDMACRO$ should evaluate to an empty string rather
> than being left untouched. Especially when used in commands, the
> $_HOSTUNDEFINEDMACRO part gets interpreted by the shell (usually empty)
> and the trailing $ is displayed plainly.
>
> Following patch is made against 3.0.5 but applies cleanly to latest git
> snapshot from git.nagiosprojects.org. It changes the behavior for custom
> macros.
>
> Does anyone see any reasons why this should not be changed?
>
It makes it impossible to use shell variables in commands.
Imagine something like this:
echo "hoopla" > $HOME/$HOSTADDRESS$
as a really, really stupid notification script (or whatever).
Will "$HOME/$" get removed, leaving "HOSTADDRESS$" just because
it's not a valid macro?
If you parse all valid macros first and then remove the remaining
ones, how would you handle
echo "hoopla" > $TMPROOT/.private/$USER/$HOSTADDRESS$
(which is a rather common layout to create user-private temporary
directories on security anal systems). After $HOSTADDRESS$ is
removed, would you then strip "$TMPROOT/.private/$" from the
command?
You could ofcourse getenv() the string after the dollar sign, but
then you'll (someday) run headlong into this:
echo "hoopla" > $TMPROOT/.private/${HOME##*/}/$HOSTADDRESS$
and then you'll spend the rest of your life extending Nagios'
shell-variable quoting code to match that of whatever shell you
happen to be using (not really, but you get the idea I'm sure).
A better way of achieving what you want is to extend the macro
syntax so that
$?_RANDOMCUSTOMVARIABLE$
expands to nothing if _RANDOMCUSTOMVARIABLE can't be located.
--
Andreas Ericsson [email protected]
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]