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