Failing event_handlers and ocsp/ochp_command silently fail & gged

[Brian A. Seklecki]

> There's no problem with pipes. You may not agree with the standard, but
> that's not a problem with pipes. It's a problem with you.

AE: No need to make it personal.

The problem is not pipes, the POSIX standard, or adherence to standards 
(*).  It's how _pipes can obfuscate the problem_, and how letting 
handlers contain them can lead to to:
  - Obfuscation
  - Problems with escaping
  - Syntax problems
  ... calling a wrapper or moving the code inside would solve some of this.

> Rather; Create a simple API that runs a process, storing everything
> interesting in a publicly declared data structure and calls a
> handler when the command is done executing.
> Preferrably the API should have a shortcut to let in-core code feed
> continuous input to it.

Sounds fine.  Or your other suggestion: Don't crunch 0,1,2,3 as 
health check results when not execing a healthcheck.


~BAS

Although its not quite noon yet on the East coast yet, so I'll take a 
moment to bash on GNU/Linux and ignoring standards:

   My current favorite is GNU libc and fclose(3) will let you fclose() a
   null  file pointer without error/warning (segfault is the expected result)




-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
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