How to handle macros with \'s in them

[Andrew Cruse]

Frost, Mark {PBG} wrote:
> Hello.  Recently, we've started running plugins that have \'s in their
> output.  Specifically, the nsclient++ disk check that would report on,
> say "C:\".
> 
> The plugin sends output like:
> 
> 	C:\ - total: 3.91 Gb - used: 3.62 Gb (93%) - free 0.29 Gb (7%)
> 
> which looks fine in Nagios' web interface.  However, when an alert
> gets generated, all I get for the service output is
> 
> 	C:
> 
> We use the common notify-by-email command for notifications.  I.e
> 
> define command {
>         command_name    notify-by-email
>         command_line    /usr/bin/printf "%b" "***** Nagios
> *****\n\nNotification Type: $NOTIFICATIONTYPE$\n\nService:
> $SERVICEDESC$\nHost: $HOSTALIAS$\nAddress: $HOSTADDRESS$\nState:
> $SERVICESTATE$\n\nDate/Time: $LONGDATETIME$\n\nAdditional
> Info:\n\n$SERVICEOUTPUT$" | /bin/mail -s "** $NOTIFICATIONTYPE$ alert
> - $HOSTALIAS$/$SERVICEDESC$ is $SERVICESTATE$ **" $CONTACTEMAIL$
> }
> 
> So unless I'm mistaken, the \ in the $SERVICEOUTPUT$ gets eaten by the
> /usr/bin/printf for the notification command.
> 
> A simple solution has eluded me.  Has anyone found a nice way to
> handle this?


Not the most elegant way of handling it, but you could write a wrapper for
your check script that passes the check paramaters along and then strips the
"\" from the output before passing it along to Nagios.  The "\" doesn't seem
like critical information so I don't think you'd really miss it.

Andrew


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Nagios-users mailing list
Nagios-users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. 
::: Messages without supporting info will risk being sent to /dev/null