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