xref: /dflybsd-src/usr.sbin/cron/doc/FEATURES (revision 86d7f5d305c6adaa56ff4582ece9859d73106103)
1*86d7f5d3SJohn Marino$FreeBSD: src/usr.sbin/cron/doc/FEATURES,v 1.4 1999/08/28 01:15:53 peter Exp $
2*86d7f5d3SJohn Marino$DragonFly: src/usr.sbin/cron/doc/FEATURES,v 1.2 2003/06/17 04:29:53 dillon Exp $
3*86d7f5d3SJohn Marino
4*86d7f5d3SJohn MarinoFeatures of Vixie's cron relative to BSD 4.[23] and SysV crons:
5*86d7f5d3SJohn Marino
6*86d7f5d3SJohn Marino--	Environment variables can be set in each crontab.  SHELL, USER,
7*86d7f5d3SJohn Marino	LOGNAME, and HOME are set from the user's passwd entry; all except
8*86d7f5d3SJohn Marino	USER can be changed in the crontab.  PATH is especially useful to
9*86d7f5d3SJohn Marino	set there.  TZ can be set, but cron ignores it other than passing
10*86d7f5d3SJohn Marino	it on through to the commands it runs.  Format is
11*86d7f5d3SJohn Marino
12*86d7f5d3SJohn Marino		variable=value
13*86d7f5d3SJohn Marino
14*86d7f5d3SJohn Marino	Blanks surrounding the '=' will be eaten; other blanks in value are
15*86d7f5d3SJohn Marino	okay.  Leading or trailing blanks can be preserved by quoting, single
16*86d7f5d3SJohn Marino	or double quotes are okay, just so they match.
17*86d7f5d3SJohn Marino
18*86d7f5d3SJohn Marino		PATH=.:/bin:/usr/bin
19*86d7f5d3SJohn Marino		SHELL=/bin/sh
20*86d7f5d3SJohn Marino		FOOBAR = this is a long blanky example
21*86d7f5d3SJohn Marino
22*86d7f5d3SJohn Marino	Above, FOOBAR would get "this is a long blanky example" as its value.
23*86d7f5d3SJohn Marino
24*86d7f5d3SJohn Marino	SHELL and HOME will be used when it's time to run a command; if
25*86d7f5d3SJohn Marino	you don't set them, HOME defaults to your /etc/passwd entry
26*86d7f5d3SJohn Marino	and SHELL defaults to /bin/sh.
27*86d7f5d3SJohn Marino
28*86d7f5d3SJohn Marino	MAILTO, if set to the login name of a user on your system, will be the
29*86d7f5d3SJohn Marino	person that cron mails the output of commands in that crontab.  This is
30*86d7f5d3SJohn Marino	useful if you decide on BINMAIL when configuring cron.h, since binmail
31*86d7f5d3SJohn Marino	doesn't know anything about aliasing.
32*86d7f5d3SJohn Marino
33*86d7f5d3SJohn Marino--	Weekdays can be specified by name.  Case is not significant, but only
34*86d7f5d3SJohn Marino	the first three letters should be specified.
35*86d7f5d3SJohn Marino
36*86d7f5d3SJohn Marino--	Months can likewise be specified by name.  Three letters only.
37*86d7f5d3SJohn Marino
38*86d7f5d3SJohn Marino--	Ranges and lists can be mixed.  Standard crons won't allow '1,3-5'.
39*86d7f5d3SJohn Marino
40*86d7f5d3SJohn Marino--	Ranges can specify 'step' values.  '10-16/2' is like '10,12,14,16'.
41*86d7f5d3SJohn Marino
42*86d7f5d3SJohn Marino--	Sunday is both day 0 and day 7 -- apparently BSD and ATT disagree
43*86d7f5d3SJohn Marino	about this.
44*86d7f5d3SJohn Marino
45*86d7f5d3SJohn Marino--	Each user gets their own crontab file.  This is a win over BSD 4.2,
46*86d7f5d3SJohn Marino	where only root has one, and over BSD 4.3, where they made the crontab
47*86d7f5d3SJohn Marino	format incompatible and although the commands can be run by non-root
48*86d7f5d3SJohn Marino	uid's, root is still the only one who can edit the crontab file.  This
49*86d7f5d3SJohn Marino	feature mimics the SysV cron.
50*86d7f5d3SJohn Marino
51*86d7f5d3SJohn Marino--	The 'crontab' command is loosely compatible with SysV, but has more
52*86d7f5d3SJohn Marino	options which just generally make more sense.  Running crontab with
53*86d7f5d3SJohn Marino	no arguments will print a cute little summary of the command syntax.
54*86d7f5d3SJohn Marino
55*86d7f5d3SJohn Marino--	Comments and blank lines are allowed in the crontab file.  Comments
56*86d7f5d3SJohn Marino	must be on a line by themselves; leading whitespace is ignored, and
57*86d7f5d3SJohn Marino	a '#' introduces the comment.
58*86d7f5d3SJohn Marino
59*86d7f5d3SJohn Marino--	(big win) If the `crontab' command changes anything in any crontab,
60*86d7f5d3SJohn Marino	the 'cron' daemon will reload all the tables before running the
61*86d7f5d3SJohn Marino	next iteration.  In some crons, you have to kill and restart the
62*86d7f5d3SJohn Marino	daemon whenever you change a crontab.  In other crons, the crontab
63*86d7f5d3SJohn Marino	file is reread and reparsed every minute even if it didn't change.
64*86d7f5d3SJohn Marino
65*86d7f5d3SJohn Marino--	In order to support the automatic reload, the crontab files are not
66*86d7f5d3SJohn Marino	readable or writable except by 'crontab' or 'cron'.  This is not a
67*86d7f5d3SJohn Marino	problem, since 'crontab' will let you do pretty much whatever you
68*86d7f5d3SJohn Marino	want to your own crontab, or if you are root, to anybody's crontab.
69*86d7f5d3SJohn Marino
70*86d7f5d3SJohn Marino--	If any output is generated by a command (on stdout OR stderr), it will
71*86d7f5d3SJohn Marino	be mailed to the owner of the crontab that contained the command (or
72*86d7f5d3SJohn Marino	MAILTO, see discussion of environment variables, above).  The headers
73*86d7f5d3SJohn Marino	of the mail message will include the command that was run, and a
74*86d7f5d3SJohn Marino	complete list of the environment that was passed to it, which will
75*86d7f5d3SJohn Marino	contain (at least) the USER (LOGNAME on SysV), HOME, and SHELL.
76*86d7f5d3SJohn Marino
77*86d7f5d3SJohn Marino--	the dom/dow situation is odd.  '* * 1,15 * Sun' will run on the
78*86d7f5d3SJohn Marino	first and fifteenth AND every Sunday;  '* * * * Sun' will run *only*
79*86d7f5d3SJohn Marino	on Sundays;  '* * 1,15 * *' will run *only* the 1st and 15th.  this
80*86d7f5d3SJohn Marino	is why we keep 'e->dow_star' and 'e->dom_star'.  I didn't think up
81*86d7f5d3SJohn Marino	this behaviour; it's how cron has always worked but the documentation
82*86d7f5d3SJohn Marino	hasn't been very clear.  I have been told that some AT&T crons do not
83*86d7f5d3SJohn Marino	act this way and do the more reasonable thing, which is (IMHO) to "or"
84*86d7f5d3SJohn Marino	the various field-matches together.  In that sense this cron may not
85*86d7f5d3SJohn Marino	be completely similar to some AT&T crons.
86