89 lines
4.0 KiB
Plaintext
89 lines
4.0 KiB
Plaintext
$Id: FEATURES,v 1.1.1.1 1994/01/05 20:40:12 jtc Exp $
|
|
|
|
Features of Vixie's cron relative to BSD 4.[23] and SysV crons:
|
|
|
|
-- Environment variables can be set in each crontab. SHELL, USER,
|
|
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 examined when it's time to run a command; if
|
|
you don't change them, they default to your /etc/passwd entry.
|
|
|
|
*DANGER*, WILL ROBINSON! This means that all 'uucp' logins should set
|
|
SHELL=/bin/sh or cron will try to use /usr/lib/uucp/uucico as the
|
|
shell. This won't work.
|
|
|
|
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.
|
|
|
|
Setting SHELL=/bin/sh will in general speed up your commands since it
|
|
is a much smaller shell than the one you probably use normally (csh
|
|
or ksh) and has enough features to work non-interactively.
|
|
|
|
-- 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, it
|
|
tells the 'cron' daemon, who reloads 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.
|