From 61b0173555ec08f2b03182c9113f1abbc40a4291 Mon Sep 17 00:00:00 2001 From: Ton Voon Date: Tue, 13 May 2003 23:20:08 +0000 Subject: [PATCH] Updated docs to include comments, contrib->main, getopts_long and verbose output levels git-svn-id: https://nagiosplug.svn.sourceforge.net/svnroot/nagiosplug/nagiosplug/trunk@508 f882894a-f735-0410-b71e-b25c423dba1c --- doc/developer-guidelines.sgml | 92 ++++++++++++++++++++++++++++++----- 1 file changed, 79 insertions(+), 13 deletions(-) diff --git a/doc/developer-guidelines.sgml b/doc/developer-guidelines.sgml index 42ad896..3edca6b 100644 --- a/doc/developer-guidelines.sgml +++ b/doc/developer-guidelines.sgml @@ -109,7 +109,42 @@ when it notifies contacts about potential problems. If you print multiple lines, you're out of luck. Remember, keep it short and to the point. - + + +
Verbose output + Use the -v flag for verbose output. You should allow multiple + -v options for additional verbosity, up to a maximum of 3. The standard + type of output should be: + + Verbose output levels + + + + Verbosity level + Type of output + + + + + 0 + Single line, minimal output. Summary + + + 1 + Single line, additional information (eg list processes that fail) + + + 2 + Multi line, configuration debug output (eg ps command used) + + + 3 + Lots of detail for plugin problem diagnosis + + + +
+
Screen Output The plug-in should print the diagnostic and just the @@ -345,9 +380,8 @@
Option Processing For plugins written in C, we recommend the C standard - getopt library for short options. If using getopt_long, check to - be sure that HAVE_GETOPT_H is defined (configure checks this and - sets the #define in common/config.h). + getopt library for short options. Getopt_long is always available. + For plugins written in Perl, we recommend Getopt::Long module. @@ -363,6 +397,7 @@ -w warning threshold (--warning) -c critical threshold (--critical) -H hostname (--hostname) + -v verbose (--verbose) In addition to the reserved options above, some other standard options are: @@ -397,6 +432,9 @@ help. Help text should fit on an 80-character width display, but may run as many lines as needed. + The option -v or --verbose should be present in all plugins. + The user should be allowed to specify -v multiple times to increase + the verbosity level, as described in .
@@ -405,7 +443,7 @@ Old style was to do things like -ct for critical time and -cv for critical value. That goes out the window with POSIX - getopt. The allowable alternatves are: + getopt. The allowable alternatives are: @@ -449,23 +487,51 @@ As always, comments are welcome - making this consistent without a host of long options was quite a hassle, and I would - suspect that there are flaws in this strategy. Perhaps clear - long-options is the most important of the above choices, but not - all POSIX systems have C libraries for long options, so the - short forms must exist as well. + suspect that there are flaws in this strategy. +
+
Coding guidelines + See GNU + Coding standards for general guidelines. +
Comments + You should use /* */ for comments and not // as some compilers + do not handle the latter form +
+
+
New submissions and patches - If you would like other to use your plugins and have it included in - the standard distribution, please include patches for the relavant - configuration files, in particular "configure.in" Otherwise submitted + If you would like others to use your plugins and have it included in + the standard distribution, please include patches for the relevant + configuration files, in particular "configure.in". Otherwise submitted plugins will be included in the contrib directory. Plugins in the contrib directory are going to be migrated to the standard plugins/plugin-scripts directory as time permits and per user - requests + requests. The minimum requirements are: + + + + The standard command options are supported (--help, --version, + --timeout, --warning, --critical) + + + It is determined to be not redundant (for instance, we would not + add a new version of check_disk just because someone had provide + a plugin that had perf checking - we would incorporate the features + into an exisiting plugin) + + + One of the developers has had the time to audit the code and declare + it ready for core + + + It should also follow code format guidelines, and use functions from +utils (perl or c or sh) rather than cooking it's own + + Patches should be submitted via the SourceForge and be announced to the mailing list. -- 2.30.2