diff options
Diffstat (limited to 'usr.sbin/cron/doc/FEATURES')
| -rw-r--r-- | usr.sbin/cron/doc/FEATURES | 84 |
1 files changed, 0 insertions, 84 deletions
diff --git a/usr.sbin/cron/doc/FEATURES b/usr.sbin/cron/doc/FEATURES deleted file mode 100644 index 821d1f3..0000000 --- a/usr.sbin/cron/doc/FEATURES +++ /dev/null @@ -1,84 +0,0 @@ -$FreeBSD$ - -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. |
