186d7f5d3SJohn Marino$FreeBSD: src/usr.sbin/cron/doc/FEATURES,v 1.4 1999/08/28 01:15:53 peter Exp $ 286d7f5d3SJohn Marino$DragonFly: src/usr.sbin/cron/doc/FEATURES,v 1.2 2003/06/17 04:29:53 dillon Exp $ 386d7f5d3SJohn Marino 486d7f5d3SJohn MarinoFeatures of Vixie's cron relative to BSD 4.[23] and SysV crons: 586d7f5d3SJohn Marino 686d7f5d3SJohn Marino-- Environment variables can be set in each crontab. SHELL, USER, 786d7f5d3SJohn Marino LOGNAME, and HOME are set from the user's passwd entry; all except 886d7f5d3SJohn Marino USER can be changed in the crontab. PATH is especially useful to 986d7f5d3SJohn Marino set there. TZ can be set, but cron ignores it other than passing 1086d7f5d3SJohn Marino it on through to the commands it runs. Format is 1186d7f5d3SJohn Marino 1286d7f5d3SJohn Marino variable=value 1386d7f5d3SJohn Marino 1486d7f5d3SJohn Marino Blanks surrounding the '=' will be eaten; other blanks in value are 1586d7f5d3SJohn Marino okay. Leading or trailing blanks can be preserved by quoting, single 1686d7f5d3SJohn Marino or double quotes are okay, just so they match. 1786d7f5d3SJohn Marino 1886d7f5d3SJohn Marino PATH=.:/bin:/usr/bin 1986d7f5d3SJohn Marino SHELL=/bin/sh 2086d7f5d3SJohn Marino FOOBAR = this is a long blanky example 2186d7f5d3SJohn Marino 2286d7f5d3SJohn Marino Above, FOOBAR would get "this is a long blanky example" as its value. 2386d7f5d3SJohn Marino 2486d7f5d3SJohn Marino SHELL and HOME will be used when it's time to run a command; if 2586d7f5d3SJohn Marino you don't set them, HOME defaults to your /etc/passwd entry 2686d7f5d3SJohn Marino and SHELL defaults to /bin/sh. 2786d7f5d3SJohn Marino 2886d7f5d3SJohn Marino MAILTO, if set to the login name of a user on your system, will be the 2986d7f5d3SJohn Marino person that cron mails the output of commands in that crontab. This is 3086d7f5d3SJohn Marino useful if you decide on BINMAIL when configuring cron.h, since binmail 3186d7f5d3SJohn Marino doesn't know anything about aliasing. 3286d7f5d3SJohn Marino 3386d7f5d3SJohn Marino-- Weekdays can be specified by name. Case is not significant, but only 3486d7f5d3SJohn Marino the first three letters should be specified. 3586d7f5d3SJohn Marino 3686d7f5d3SJohn Marino-- Months can likewise be specified by name. Three letters only. 3786d7f5d3SJohn Marino 3886d7f5d3SJohn Marino-- Ranges and lists can be mixed. Standard crons won't allow '1,3-5'. 3986d7f5d3SJohn Marino 4086d7f5d3SJohn Marino-- Ranges can specify 'step' values. '10-16/2' is like '10,12,14,16'. 4186d7f5d3SJohn Marino 4286d7f5d3SJohn Marino-- Sunday is both day 0 and day 7 -- apparently BSD and ATT disagree 4386d7f5d3SJohn Marino about this. 4486d7f5d3SJohn Marino 4586d7f5d3SJohn Marino-- Each user gets their own crontab file. This is a win over BSD 4.2, 4686d7f5d3SJohn Marino where only root has one, and over BSD 4.3, where they made the crontab 4786d7f5d3SJohn Marino format incompatible and although the commands can be run by non-root 4886d7f5d3SJohn Marino uid's, root is still the only one who can edit the crontab file. This 4986d7f5d3SJohn Marino feature mimics the SysV cron. 5086d7f5d3SJohn Marino 5186d7f5d3SJohn Marino-- The 'crontab' command is loosely compatible with SysV, but has more 5286d7f5d3SJohn Marino options which just generally make more sense. Running crontab with 5386d7f5d3SJohn Marino no arguments will print a cute little summary of the command syntax. 5486d7f5d3SJohn Marino 5586d7f5d3SJohn Marino-- Comments and blank lines are allowed in the crontab file. Comments 5686d7f5d3SJohn Marino must be on a line by themselves; leading whitespace is ignored, and 5786d7f5d3SJohn Marino a '#' introduces the comment. 5886d7f5d3SJohn Marino 5986d7f5d3SJohn Marino-- (big win) If the `crontab' command changes anything in any crontab, 6086d7f5d3SJohn Marino the 'cron' daemon will reload all the tables before running the 6186d7f5d3SJohn Marino next iteration. In some crons, you have to kill and restart the 6286d7f5d3SJohn Marino daemon whenever you change a crontab. In other crons, the crontab 6386d7f5d3SJohn Marino file is reread and reparsed every minute even if it didn't change. 6486d7f5d3SJohn Marino 6586d7f5d3SJohn Marino-- In order to support the automatic reload, the crontab files are not 6686d7f5d3SJohn Marino readable or writable except by 'crontab' or 'cron'. This is not a 6786d7f5d3SJohn Marino problem, since 'crontab' will let you do pretty much whatever you 6886d7f5d3SJohn Marino want to your own crontab, or if you are root, to anybody's crontab. 6986d7f5d3SJohn Marino 7086d7f5d3SJohn Marino-- If any output is generated by a command (on stdout OR stderr), it will 7186d7f5d3SJohn Marino be mailed to the owner of the crontab that contained the command (or 7286d7f5d3SJohn Marino MAILTO, see discussion of environment variables, above). The headers 7386d7f5d3SJohn Marino of the mail message will include the command that was run, and a 7486d7f5d3SJohn Marino complete list of the environment that was passed to it, which will 7586d7f5d3SJohn Marino contain (at least) the USER (LOGNAME on SysV), HOME, and SHELL. 7686d7f5d3SJohn Marino 7786d7f5d3SJohn Marino-- the dom/dow situation is odd. '* * 1,15 * Sun' will run on the 7886d7f5d3SJohn Marino first and fifteenth AND every Sunday; '* * * * Sun' will run *only* 7986d7f5d3SJohn Marino on Sundays; '* * 1,15 * *' will run *only* the 1st and 15th. this 8086d7f5d3SJohn Marino is why we keep 'e->dow_star' and 'e->dom_star'. I didn't think up 8186d7f5d3SJohn Marino this behaviour; it's how cron has always worked but the documentation 8286d7f5d3SJohn Marino hasn't been very clear. I have been told that some AT&T crons do not 8386d7f5d3SJohn Marino act this way and do the more reasonable thing, which is (IMHO) to "or" 8486d7f5d3SJohn Marino the various field-matches together. In that sense this cron may not 8586d7f5d3SJohn Marino be completely similar to some AT&T crons. 86