On Mon, 2007-09-03 at 06:28 -0700, Darren J Moffat wrote:
> I'm sponsoring this OpenSolaris case for Chris Gerhard. It has some possible
> standards impact but I believe based on previous discussions this should
> be acceptable, if it wasn't for the standards impact this would likely have
> been self-review.
Might I suggest a minor extension? From a quick glance at a *BSD
(Vixie) crontab(5) manpage, I see one piece I could really use: MAILTO.
In addition to LOGNAME, HOME, and SHELL, cron(8) will look at MAILTO if
it has any reason to send mail as a result of running commands in
``this'' crontab. If MAILTO is defined (and non-empty), mail is sent
to the user so named. If MAILTO is defined but empty (MAILTO=""), no
mail will be sent.
Secondly: I think ALLOW_EXTENSIONS is not necessary. This is another
case where an extension gives meaning to what was formerly a syntax
error.
There appears to be extensive implementation experience with this sort
of extension on other platforms. In the absence of evidence that there
is real crontab-manipulating code out there which will be broken by this
extension, I don't think we need the ALLOW_EXTENSIONS knob (except
*possibly* as a hedge to enable backport to an older release, and even
then I'm skeptical).
Rationale:
If an application is in complete control of the entire crontab file
contents and is unaware of the extension, it won't use it and no problem
can result.
If an application is not in complete control of the crontab file, then
administrators need to take responsibility for the contents and thus
need to avoid introducing environment variables which will disrupt
application-added crontab entries.
- Bill
