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