From owner-freebsd-current@FreeBSD.ORG Mon Jan 2 23:01:41 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C73721065670; Mon, 2 Jan 2012 23:01:41 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) by mx1.freebsd.org (Postfix) with ESMTP id 7093E8FC0A; Mon, 2 Jan 2012 23:01:41 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 516F625D3810; Mon, 2 Jan 2012 23:01:40 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 703C9BD8585; Mon, 2 Jan 2012 23:01:39 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id 3-Roi1seXu+u; Mon, 2 Jan 2012 23:01:38 +0000 (UTC) Received: from orange-en1.sbone.de (orange-en1.sbone.de [IPv6:fde9:577b:c1a9:31:cabc:c8ff:fecf:e8e3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 0B385BD8584; Mon, 2 Jan 2012 23:01:38 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Bjoern A. Zeeb" In-Reply-To: <4F02350D.2050500@FreeBSD.org> Date: Mon, 2 Jan 2012 23:01:37 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F023387.1060300@FreeBSD.org> <4F02350D.2050500@FreeBSD.org> To: Doug Barton X-Mailer: Apple Mail (2.1084) Cc: Garrett Cooper , FreeBSD current mailing list Subject: Re: periodic emails X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2012 23:01:42 -0000 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 = wrote: >>> On 01/02/2012 14:14, Garrett Cooper wrote: >>>=20 >>>> 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 . >>>=20 >>> The periodic scripts are badly in need of attention, so effort in = that >>> area is much appreciated. >>>=20 >>> 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. >>=20 >> That works too, assuming that rc.subr isn't too rc(5) centric. >=20 > 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. >=20 >> Thanks for the feedback! >=20 > 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 _show_success variable controls the masking of this = out- put. 1 The script has produced some notable information in its = output. The _show_info variable controls the masking of this = out- put. 2 The script has produced some warnings due to invalid = configuration settings. The _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 --=20 Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do!