85 lines
3.8 KiB
Plaintext
85 lines
3.8 KiB
Plaintext
$FreeBSD$
|
|
|
|
Features of Vixie's cron relative to BSD 4.[23] and SysV crons:
|
|
|
|
-- Environment variables can be set in each crontab. SHELL, USER,
|
|
LOGNAME, and HOME are set from the user's passwd entry; all except
|
|
USER can be changed in the crontab. PATH is especially useful to
|
|
set there. TZ can be set, but cron ignores it other than passing
|
|
it on through to the commands it runs. Format is
|
|
|
|
variable=value
|
|
|
|
Blanks surrounding the '=' will be eaten; other blanks in value are
|
|
okay. Leading or trailing blanks can be preserved by quoting, single
|
|
or double quotes are okay, just so they match.
|
|
|
|
PATH=.:/bin:/usr/bin
|
|
SHELL=/bin/sh
|
|
FOOBAR = this is a long blanky example
|
|
|
|
Above, FOOBAR would get "this is a long blanky example" as its value.
|
|
|
|
SHELL and HOME will be used when it's time to run a command; if
|
|
you don't set them, HOME defaults to your /etc/passwd entry
|
|
and SHELL defaults to /bin/sh.
|
|
|
|
MAILTO, if set to the login name of a user on your system, will be the
|
|
person that cron mails the output of commands in that crontab. This is
|
|
useful if you decide on BINMAIL when configuring cron.h, since binmail
|
|
doesn't know anything about aliasing.
|
|
|
|
-- Weekdays can be specified by name. Case is not significant, but only
|
|
the first three letters should be specified.
|
|
|
|
-- Months can likewise be specified by name. Three letters only.
|
|
|
|
-- Ranges and lists can be mixed. Standard crons won't allow '1,3-5'.
|
|
|
|
-- Ranges can specify 'step' values. '10-16/2' is like '10,12,14,16'.
|
|
|
|
-- Sunday is both day 0 and day 7 -- apparently BSD and ATT disagree
|
|
about this.
|
|
|
|
-- Each user gets their own crontab file. This is a win over BSD 4.2,
|
|
where only root has one, and over BSD 4.3, where they made the crontab
|
|
format incompatible and although the commands can be run by non-root
|
|
uid's, root is still the only one who can edit the crontab file. This
|
|
feature mimics the SysV cron.
|
|
|
|
-- The 'crontab' command is loosely compatible with SysV, but has more
|
|
options which just generally make more sense. Running crontab with
|
|
no arguments will print a cute little summary of the command syntax.
|
|
|
|
-- Comments and blank lines are allowed in the crontab file. Comments
|
|
must be on a line by themselves; leading whitespace is ignored, and
|
|
a '#' introduces the comment.
|
|
|
|
-- (big win) If the `crontab' command changes anything in any crontab,
|
|
the 'cron' daemon will reload all the tables before running the
|
|
next iteration. In some crons, you have to kill and restart the
|
|
daemon whenever you change a crontab. In other crons, the crontab
|
|
file is reread and reparsed every minute even if it didn't change.
|
|
|
|
-- In order to support the automatic reload, the crontab files are not
|
|
readable or writable except by 'crontab' or 'cron'. This is not a
|
|
problem, since 'crontab' will let you do pretty much whatever you
|
|
want to your own crontab, or if you are root, to anybody's crontab.
|
|
|
|
-- If any output is generated by a command (on stdout OR stderr), it will
|
|
be mailed to the owner of the crontab that contained the command (or
|
|
MAILTO, see discussion of environment variables, above). The headers
|
|
of the mail message will include the command that was run, and a
|
|
complete list of the environment that was passed to it, which will
|
|
contain (at least) the USER (LOGNAME on SysV), HOME, and SHELL.
|
|
|
|
-- the dom/dow situation is odd. '* * 1,15 * Sun' will run on the
|
|
first and fifteenth AND every Sunday; '* * * * Sun' will run *only*
|
|
on Sundays; '* * 1,15 * *' will run *only* the 1st and 15th. this
|
|
is why we keep 'e->dow_star' and 'e->dom_star'. I didn't think up
|
|
this behaviour; it's how cron has always worked but the documentation
|
|
hasn't been very clear. I have been told that some AT&T crons do not
|
|
act this way and do the more reasonable thing, which is (IMHO) to "or"
|
|
the various field-matches together. In that sense this cron may not
|
|
be completely similar to some AT&T crons.
|