crontab entry environment variables [PSARC/2007/503 FastTrack

[Richard L. Hamilton]

> 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.
[...]

Since the proposed environment variable settings
"continue to effect all entries below them until new
entries are listed in the file", how about another
extension: a keyword like SETDEFAULTENV?  That way, if one
wished to put that as the last line of a crontab, and some random
application appended entries (possibly flagged with a shell comment
or suchlike so it could recognize and edit or remove them later as needed),
they would be unaffected.  That might allow one to use the extensions
for manually entered crontab entries and yet at least in certain cases
coexist better with software-generated entries made by programs unaware
of the extensions.

Also, not related to crontab per se, but some sites have a requirement
that email have certain markings or disclaimers or whatever added to it.
The ability to specify (in /etc/default/cron) an optional filter that would be
applied to output prior to being passed to /usr/bin/mail would be helpful;
otherwise, the attempts to satisfy such a requirement get inordinately
convoluted.  Alternatively, a way to specify something to use in place of
/usr/bin/mail (but assumed to have the same command-line syntax) would
be handy; that way one could create a shell wrapper around /usr/bin/mail
that would only be used by cron, which could accomplish the filtering as
desired.

Finally, a way (and this could be either via /etc/default/cron or
via another variable in the crontab) to optionally specify an alternative, more
descriptive subject line for such email might be nice, esp. if it could be
subjected to some printf-like substitutions, one of which should be the
nodename (cron email from multiple systems can sometimes only be
distinguished by inspecting the Received: headers, which is very ugly).
 
 
This message posted from opensolaris.org