Boyd Stephen Smith Jr. wrote:
> In <[🔎] 4A01AC7B.4010101@fgm.com>, Barclay, Daniel wrote:
>> Does Debian have any utility to address the following situation?
>
> Not that I know of.
>
>> I have some scripts that I run both manually and as cron jobs. The
>> scripts generate stdout/stderr output reporting what they're doing.
>>
>> I want to see the output when I run the scripts manually. However, when
>> the scripts are run by cron, normally I don't want cron to e-mail me that
>> bulky output for each run--I want the output (the full output) only when
>> the output is different than expected (e.g., if something has gone wrong
>> or has changed, which I want to notice).
No one seems to be reading that last line.
I'm not talking (just) about errors detected by the scripts. I'm talking
about changes to progress messages emitted by the scripts, mostly like the
way logcheck filters can suppress expected/recognized message in logs but
e-mail anything unexpected or unrecognized (except that logcheck reports
only the unexpected messages).
> For maximum utility, in particular use with cron, your scripts should follow
> two Unix philosophies: (1) If everything is going as expected, no output is
> required. (2) If the task was not completed, exit with a non-zero value.
>
> If you follow the first, your script can run from cron with no problems and
> users can opt-in to extra output with a "-v" option or similar. You might
> even be *really* nice and give a "-q" option, too. Then you could even make
> the "-v" the default for interactive calls and "-q" the default for non-
> interactive calls.
>
> If you follow the second, you can always use something like so for even
> quieter cron jobs:
> output=$(my_script and my_args 2>&1)
> if [ $? -ne 0 ]; then
> printf >&2 '%s\n' "$output"
> fi
>
> So, my first advice is to fix your scripts so they act like Unix utilities.
That's what I'm trying to do by wrapping them in a script that does what I
described--that suppresses all output when output from the underlying
script is as expected, but which generates output (all output from the
underlying script), and possibly returns a different exit code, when the
output of the underlying script isn't quite as expected.
>> I started to write a wrapper script to take a command to execute and a
>> file of regular expressions defining expected output lines ...
...
> If you can't / won't fix your scripts, Here's a start on that wrapper:
Yes, I have a start.
Daniel
--
(Plain text sometimes corrupted to HTML "courtesy" of Microsoft Exchange.) [F]