head     2.0;
access   ;
symbols  V2:2.0;
locks    ; strict;
comment  @@;


2.0
date     88.12.10.04.57.35;  author vixie;  state Exp;
branches ;
next     1.2;

1.2
date     88.11.13.17.11.26;  author vixie;  state Exp;
branches ;
next     1.1;

1.1
date     87.07.10.11.36.55;  author paul;  state Exp;
branches ;
next     ;


desc
@@


2.0
log
@V2 Beta
@
text
@$Header: INFO.features,v 1.2 88/11/13 17:11:26 vixie Exp $

Features of Vixie's cron relative to BSD 4.[23] and SysV crons:

--	Environment variables can be set in each crontab.  SHELL, USER,
	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 examined when it's time to run a command; if
	you don't change them, they default to your /etc/passwd entry.

	*DANGER*, WILL ROBINSON! This means that all 'uucp' logins should set
	SHELL=/bin/sh or cron will try to use /usr/lib/uucp/uucico as the
	shell.  This won't work.

	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.

	Setting SHELL=/bin/sh will in general speed up your commands since it
	is a much smaller shell than the one you probably use normally (csh
	or ksh) and has enough features to work non-interactively.

--	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, it
	tells the 'cron' daemon, who reloads 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.
@


1.2
log
@errors
@
text
@d1 1
a1 1
$Header: INFO.features,v 1.1 87/07/10 11:36:55 paul Exp $
a4 2
--	(questionable)  There is no cron.allow or cron.deny file.

d21 1
a21 1
	Above, FOOBAR would get 'this is a long blanky example' as its value.
d55 1
a55 1
	feature was taken from the SysV cron.
d59 1
a59 1
	no arguments will print a complete summary of the command syntax.
d63 1
a63 3
	a '#' introduces the comment.  I don't know if BSD or ATT support
	this, and I've heard conflicting stories which makes me think that
	some versions have it and others don't.
d65 1
a65 1
--	(big win) If the 'crontab' command changes anything in any crontab, it
d68 2
a69 1
	daemon whenever you change a crontab.
d74 1
a74 1
	want to your own crontab.
d81 1
a81 1
	contain (at least) the USER, HOME, and SHELL.
d86 3
a88 1
	is why we keep 'e->dow_star' and 'e->dom_star'.
@


1.1
log
@Initial revision
@
text
@d1 2
d71 2
a72 2
	next iteration.  In ATT and BSD cron, you have to kill and restart the
	daemon yourself.  (Debatable: some ATT crons do this)
a89 5

$Header$
$Source$
$Revision$
$Log$
@
