[Nagiosplug-devel] nagios-plugins.ini & argument parsing

[Thomas Guyot-Sionnest]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 17/03/08 06:39 AM, Ton Voon wrote:
> On 15 Mar 2008, at 20:17, Thomas Guyot-Sionnest wrote:
> 
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 14/03/08 08:01 PM, Thomas Guyot-Sionnest wrote:
> 
>> I started implementing this part and fixing bugs in parse_ini.c, and  
>> so
>> far I went across two big differences in ini handling:
>>
>> 1. N::P allows '#' to be part of the argument, while parse_ini treat
>> them as comments. Since it's a one-line change I left the original
>> behavior in parse_ini (mainly because the ini/tests have to be changed
>> too) but I really think '#' should be allowed.
> 
> So comments can only be entered if # is the first character on a line?  
> That sounds like a reasonable restriction.

There can be spaces before a comment (and probably comments after a
section header too), but not a comment after a <data>=<value> line. i.e.
right now the following lines:

foo = bar # this is a comment
foobar = some_data_containing_a_#_in_the_middle

will result in:

- --foo=bar
- --foobar-some_data_containing_a_

Once I disable comments there it will change to (ps: I didn't quoted the
value part here, but in the prugins it will be passed as only one argument):

- --foo=bar # this is a comment
- --foobar-some_data_containing_a_#_in_the_middle

To be able to pass a # in the value we'll have to forbid comments there.
This is really easy to change, but I'll have to change the tests too.

>> 2. N::P seems do do some smart parsing based on getopts... in either
>> case it doesn't allow parameters without values (no '=' sign on the
>> line) while parse_ini does, and append the '=' is there's one.
>>
>>
>> While I'd be tempted to follow N::P's behavior for #2, this raises one
>> question: N::P is able to make the difference between parameters that
>> requires arguments and those that don't and could smartly insert an
>> empty arg if there's nothing after the '='. This means we wouldn't be
>> able to emulate empty arguments in the c plugins as long as we don't
>> implement N::P-like argument parsing routines.
>>
>> Alternatively, I could append an empty argument when there's a '=' and
>> keep allowing empty arguments, but for consistency I guess we should
>> also allow it in N::P (Moth may want to use the config. This also  
>> seems
>> to be a violation of the ini standard. In a perfect world we could  
>> just
>> always add empty arguments but it seems that some backward- 
>> compatibility
>> stuff fail with that. I could also reject lines missing a '=' and  
>> never
>> add an argument since there aren't many plugins that require empty  
>> args...
>>
>> So for now I'll follow N::P behavior and never add an empty argument.
>> The code isn't even used yet so this is still open for comments.
> 
> I'm not following the problem here. Can you provide examples?

This is a problem only if you wish to provide an empty string as a
parameter. I believe the original idea of whoever wrote parse_ini was
that a parameter without = sign would be a parameter without argument,
and a parameter with an = sign and to value would be an empty argument.
N::P forbid parameters without = sign so the config file would be
incompatible.

The way I understand it, N::P detects if there's an required argument
and sets an empty string as the argument if needed. so the following line:

label=

would either set a flag parameter to true or set the label to an empty
string depending on the way it is defined.

Now I realize this still leaves one issue, so the only option is to
avoid these cases in our plugins. Let's say you have a --label option
that takes an optional argument. without argument, the label is
determined automatically so ion your command line you can write:

- --label --other-args => label determined automatically
- --label=something <or> --label something => you define the label
- --label '' => you want an empty label

so the third case wouldn't work with ini files. In other words we
shouldn't allow optional arguments with empty argument (either make the
argument required, or make the default to an empty string).

There might be ways to work around this in our plugins too... As i
convert them I will look for special cases and see what I can do.

Thomas
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFH3l9I6dZ+Kt5BchYRAuZ8AKDLUHNFR3oODNL1c/hMgFVmLNVD2gCdEKV3
5dCqiHmIvd1ffYd1fdcYtJw=
=rWsB
-----END PGP SIGNATURE-----