Refactoring calendar(1) (was: svn commit: r365984 - head/usr.bin/calendar/calendars)

[Greg Balfour]

On Sun, Sep 27, 2020 at 11:57 PM Greg 'groggy' Lehey <grog at freebsd.org> wrote:
>
> On Sunday, 27 September 2020 at 23:25:20 -0500, Greg Balfour wrote:
> > On Thu, Sep 24, 2020 at 09:07:08AM +1000, Greg 'groggy' Lehey wrote:
> >>
> >> While I have your attention, does anybody think that the -a option of
> >> calendar(1) is worth keeping?  It goes through *all* calendar files on
> >> a system and mails them to the owner.  It has the interesting side
> >> effect (we wouldn't want to call it a bug) that root gets three copies
> >> (one each for root, toor and daemon).  I can't see anything useful
> >> there that a per-user cron job can't do.
> >
> > I actually use the -a option.  But it hasn't fully worked since 10.0-RELEASE.
> > See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205580
> > Still present in 12.2-BETA2.
>
> Interesting.
>
> > I maintain a local set of patches that solves this bug, but it
> > requires the installation of the tradcpp port/package so I've never
> > shared them, but would if someone wants them.
>
> You could add them to the bug report; arguably they would point to a
> way to fix it without tradcpp.  But my real concern is described in
> bug 246943, and so far I don't see a clean solution for that.
>
> Does root have a calendar file on your systems?  If so, how do you
> handle the multiple emails?  Your input on 246943 would be
> interesting.

I've added my patch to bug 205580.

As fas as bug 246943 goes, I've never had a .calendar in root so
I've never had to consider this issue.  But I would agree with
comment #4 in the report.  For a fix, I think adding a knob in
calendar files per comment #13 is the best solution.

However I would not be against removing the -a flag.  I would just
refactor my use case of calendar(1).  I'm tired of keeping my patch
up to date so I may just go that route anyway.