[Nagiosplug-devel] RFC: Plugins config file (final proposal)

[sean finney]

On Thu, 2007-02-08 at 09:20 +0000, Ton Voon wrote:
> > Ok. Three things:
> >
> > - for packages, we probably want to make sure we ship with an empty
> >   (or all commented out) config file, because otherwise I imagine  
> > we'll
> >   get some very confused people wondering where these 'magic' extra
> >   options come from
> 
> Agreed. A commented out initial config file with some sensible  
> examples is a good idea.

+1.  

> > - does a --default-opts=foobar override this implicit check? i.e.
> >   we don't check --default-opts=plugin_name if --defauult-opts=foobar
> >   is set?
> 
> Sorry, this is my bad wording in the RFC. The idea of the text is  
> that a plugin developer does not have to define --default-opts using  
> getopt_long or Nagios::Plugin::Getopts to have that option available  
> - it should come for free, such as with --version and --help.

this will make a requirement on the c programs that progname is
accessible as an extern char *, just fyi.  when i implemented the
ini routines i wasn't sure if that was acceptable so i coded around
it (the default section name is passed allong with the --default-opts
option value).  

> I can see this being okay with Nagios::Plugin, but I'm not sure if it  
> is best if the C implementation does it transparently (it is  
> technically possible because if you are calling np_getopt_long, this  
> routine could tack on the required information). Sean?

see above.  if it's acceptable then i see no reason not to do all
the processing "for free" as part of np_getopt_long.

> You still need to explicitly say --default-opts= to kick the default  
> options in. This provides backwards compatibility with current syntax.

when i wrote the routines i assumed the opposite: that the defaults
would be read by, well, default :).  so in the current parse_ini code
you would disable default option reading by specifying an empty
string for the defaults location.  personally i'm more in favor of
this because "defaults should on by default".

if we're shipping a blank/commented ini file, it won't cause that
much confusion.  oh, btw a minor detail: we should make sure that "make
install" doesn't override the default file if it already exists.  but
in any event i'll acquiesce to the majority opinion if you guys
disagree.  however in that case i'd suggest "--default-opts" without
the "=" (making it an optional argument). 



	sean
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
URL: <https://www.monitoring-plugins.org/archive/devel/attachments/20070208/f278fc9b/attachment.sig>