Re: periodic emails

On 2. Jan 2012, at 22:51 , Doug Barton wrote:

> On 01/02/2012 14:49, Garrett Cooper wrote:
>> On Mon, Jan 2, 2012 at 2:45 PM, Doug Barton <dougb_at_freebsd.org> wrote:
>>> On 01/02/2012 14:14, Garrett Cooper wrote:
>>> 
>>>>    How does this look for starters? The attached patch's goal is to
>>>> provide a generic, rc(5)-like infrastructure that would quiet down the
>>>> periodic emails for 120.clean-preserve .
>>> 
>>> The periodic scripts are badly in need of attention, so effort in that
>>> area is much appreciated.
>>> 
>>> Regarding your patch, rather than copying functions from rc.subr, why
>>> not just source it? Yes, you will get more than you need, but I think
>>> that the virtue of not having to maintain the same code in 2 places far
>>> outweighs that minor drawback.
>> 
>>    That works too, assuming that rc.subr isn't too rc(5) centric.
> 
> Well of course it's rc-centric, but that's not the point. :)  If you're
> going to be using the exact same code from rc.subr, you might as well
> just source it. The things that you'll get by doing that which are only
> relevant to rc you just ignore.
> 
>> Thanks for the feedback!
> 
> Glad to help.

While the checkyesno code for sure is great to handle all these options
everywhere and doing some serious cleanup sweep.  I am all in favour of this.

But isn't the real problem here deferring the output of the header depending
on the other output or even just the correct exit code?

Looking at periodic(8) it says:

     Each script is required to exit with one of the following values:

     0     The script has produced nothing notable in its output.  The
           <basedir>_show_success variable controls the masking of this out-
           put.

     1     The script has produced some notable information in its output.
           The <basedir>_show_info variable controls the masking of this out-
           put.

     2     The script has produced some warnings due to invalid configuration
           settings.  The <basedir>_show_badconfig variable controls the mask-
           ing of this output.

     >2    The script has produced output that must not be masked.


Could it even be that if setting the correct "*_show_*" config option
could do the right thing for me already?  I have no clue how that "masking" is
done and in which category "has not produced any output but the heading"
would fall into and if other things would possibly be hidden as well?

/bz

-- 
Bjoern A. Zeeb                                 You have to have visions!
   It does not matter how good you are. It matters what good you do!