Exploding check commands batman ...

[Paul L. Allen]

Andreas Ericsson writes: 

> Paul L. Allen wrote:

>>   Variable is      Is defined?    Boolean val    Num val    String val
>>   -----------      -----------    --------       -------    ----------
>>   uninitialized    NO             false          0          null string
>>   null string      yes            false          0          null string
>>   number 0         yes            false          0          "0"
>>   string "0"       yes            false          0          "0"
>  
> 
> Note that all boolean values here are false.

Outside of strict mode they are all false.  Inside strict mode, which
the plugin guidelines encourage, the boolean value of an uninitialized
variable is "fatal error." 

>>   string "0.0"     yes            TRUE           0          "0.0"
>>   string "00"      yes            TRUE           0          "00"
> 
> These are no longer null-strings in any sense, so they aren't very 
> interesting.

They are not null strings, but they do have the numeric value zero yet
have a different boolean value than either 0 or '0'.  A potential cause
of surprises because a simple $opt_x = 20 unless ($opt_x) is going to
behave differently from $opt_x ||= 20 if the plugin is given -x 0.0
or -x 00.  Usually perl's implicit type conversions help you, but
sometimes they turn around and bite you. 

>> In strict mode uninitialized variables cannot be used in comparisons.
>> So if somebody does manage to do something that results in a variable
>> holding an option being uninitialized, as opposed to being initialized
>> with the null string,
> 
> This won't be possible.

If you're absolutely certain it won't be possible, then there no need
to cope with that situation other than being paranoid about coding
defensively. 

> I was thinking along the lines of this; 
> 
> command_name  check_foo_command
> command_line  check_foo -H $HOSTADDRESS$ -C "$ARG1$" -p "$ARG2$"

Of course this has problems when the community string is 'foo"bar', so
Nagios will have to do some escaping before calling plugins.  But I'm
sure you already thought of that. 

> So, the resulting command turns out to 
> 
> check_foo -H host -C bar -p "" 
> 
> which means the imaginary variable $port will be set to the null-string 
> and thus it will be defined but will evaluate to false when being 
> evaluated as a boolean expression, as it would have if it wasn't specified 
> at all.

That should probably work, modulo embedded double quotes.  But people are
surprisingly inventive and the GetOpt module has some strange twists and
turns in it that probably haven't been fully verified for correctness, so
it's conceivable that certain input could result in unitialized variables.
Which is why I'd probably code a plugin defensively, just to be on the safe
side. 

-- 
Paul Allen
Softflare Support 



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
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