diff options
Diffstat (limited to 'usr.sbin/cron/doc/FEATURES')
| -rw-r--r-- | usr.sbin/cron/doc/FEATURES | 83 |
1 files changed, 83 insertions, 0 deletions
diff --git a/usr.sbin/cron/doc/FEATURES b/usr.sbin/cron/doc/FEATURES new file mode 100644 index 000000000000..71b1486a8e01 --- /dev/null +++ b/usr.sbin/cron/doc/FEATURES @@ -0,0 +1,83 @@ + +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. |