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