Exploding check commands batman ...

[Andreas Ericsson]

Paul L. Allen wrote:
> 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'.

How on earth does that matter when the string initializing them will 
either be a null-string or perhaps not a null-string? I don't think you 
quite understand what I mean here.

>>> 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.
> 

Naturally. That community string would fail with the current code and 
there's no sane way of making it pass (short of escaping it manually, 
which is what one needs to do today anyway). The thing I'm suggesting 
won't break something that's working today.

-- 
Andreas Ericsson                   andreas.ericsson at op5.se
OP5 AB                             www.op5.se
Lead Developer


-------------------------------------------------------
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