Hi, clean_macro_chars() basically removes illegal_output_chars from char *macro if(options & STRIP_ILLEGAL_MACRO_CHARS).
Now, by default '\' is not an illegal output char, so it is not stripped. However that can cause problems if e.g. we have a command_line plugin arg0 $STRIPPED_MACRO$ arg2 Consider: $STRIPPED_MACRO$ = normal plugin sees: arg0: arg0 arg1: normal arg2: arg2 All is well. However, if: $STRIPPED MACRO$ = foo\ arg0: arg0 arg1: foo arg2 arg2: NULL The trailing backslash from foo cases the space to be backslashed. It can be avoided by putting in two spaces after $STRIPPED_MACRO$ in the command_line but that isn't quite intuitive, is it? This value could arise from the before-stripping values of $STRIPPED_MACRO$: "foo\", "foo\$", "foo\>" etc. I suggest that if stripping is to be truly safe, somehow it should be possible to avoid trailing backslashes as that messes up the args given to plugins. Peter (Yes, in another thread in nagios-devel I'm talking about Custom Object Variables and cleansing, but I think this applies to cleansing in general so I post it as a separate subject. Hope that is ok.) -- Peter Valdemar Mørch http://www.morch.com ------------------------------------------------------------------------------ Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d _______________________________________________ Nagios-users mailing list Nagios-users@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