mail

source code of crond

[ this is really old mail that came to me in response to my 1986 posting
  to usenet asking for feature suggestions before releasing the first 
  version of cron.  it is presented here for its entertainment value.
  --vix ]

$Id: MAIL,v 1.1 1993/12/28 08:30:36 vixie Exp $

From ptsfa!lll-crg!ames!acornrc!bob Wed Dec 31 10:07:08 1986
Date: Wed, 31 Dec 86 08:59:31 pst
From: lll-crg!ames!acornrc!bob (Bob Weissman)
To: ptsfa!vixie!paul
Status: RO

Sure, here's a suggestion: I'd like to be able to run a program, say,
every two hours.  Current cron requires me to write
0,2,4,6,8,10,12,14,16,18,20,22 in the hours field.  How about a notation
to handle this more elegantly?

<<	Okay, I've allowed 0-22/2 as a means of handling this.
	The time specification for my cron is as follows:
		specification = range {"," range}
		range = (start "-" finish ["/" step]) | single-unit
	This allows "1,3,5-7", which the current cron doesn't (it won't
	do a range inside a list), and handles your specific need.	>>

From drw@mit-eddie Wed Dec 31 18:25:27 1986
Date: Wed, 31 Dec 86 14:28:19 est
From: drw@mit-eddie (Dale Worley)
To: mit-eddie!vixie!paul
Status: RO

We have a lot of lines in our crontab of the form

	00 12 * * * su user < /usr/users/user/script.file

This barfs (silently!) on our system (Dec Ultrix 1.2 == 4.2bsd) if
user's shell is csh.  This, I am told, is because csh requires that
the environment be set up in certain ways, which cron doesn't do.
(Actually, I believe, it is because /etc/rc, which runs cron, doesn't
set up the environment enough for csh to run, and cron just inherits
the situation.)  Anyway, the point is that if you find out what csh
really needs in its environment, you might want to set up cron to
provide some reasonable defaults (if it isn't supplied by cron's
parent).  Also, could you tell me what csh needs, if you find out, so
we can hack our /etc/rc?

<<	well, the environment IS a problem. processes that cron forks
	will inherit the environment of the person who ran the cron
	daemon... I plan to edit out such useless things as TERMCAP,
	TERM, and the like; supply correct values for HOME, USER, CWD,
	and whatever else comes to mind.  I'll make sure csh works...	>>
From ptsfa!ames!seismo!dgis!generous Thu Jan  1 07:33:17 1987
Date: Thu Jan 1 10:29:20 1987
From: ames!seismo!dgis!generous (Curtis Generous)
To: nike!ptsfa!vixie!paul
Status: RO

Paul:

One of the limitations of the present versions of cron is the lack
of the capability of specifying a way to execute a command every
n units of time.

Here is a good example:

# Present method to start up uucico
02,12,22,32,42,52 * * * * 	exec /usr/lib/uucp/uucico -r1

# New method ?? (the ':' here is just one possibility for syntax)
02:10 * * * *			exec /usr/lib/uucp/uucico -r1

This method would prove very helpful for those programs that get started
every few minutes, making the entry long and not easily readable.  The first
number would specify the base time, and the second number the repetition
interval.

<<	Good idea, but bob@acornrc beat you to it.  I used '/' instead of
	':'.  This is my personal preference, and seems intuitive when you
	think of the divide operator in C... Does anyone have a preference? >>

From ptsfa!lll-lcc!seismo!decuac!c3pe!c3engr!charles Thu Jan  1 17:04:24 1987
From: lll-lcc!seismo!c3pe!c3engr!charles (Charles Green)
To: c3pe!decuac!dolqci!vrdxhq!seismo!lll-lcc!ptsfa!vixie!paul
Date: Thu Jan  1 19:22:47 1987
Status: RO

Well, this isn't a compatible extension, but I have in times past wondered
about a facility to let you start a process at intervals of, say, 17 minutes,
instead of particular minutes out of each hour.

<<	This was a popular request!	>>

From seismo!uwvax!astroatc!nicmad!norvax!mann Sun Jan  4 13:04:01 1987
Date: Fri, 2 Jan 87 09:23:53 cst
From: lll-lcc!seismo!uwvax!astroatc!nicmad!norvax!mann (Tom Mann)
To: ptsfa!vixie!paul
Status: RO

I'm not sure if it is in cron (either SysV or BSD ... if it is, I haven't
figured it out ) but a comment feature would SURE BE NICE!.
There are times when I want to comment out an entry
for a period of time; it might also make it a lot more legible.

<<	My cron allows blank lines and standard #-type comments.  I know
	that one BSD4.2 cron I've used had it.  I don't know about SysV.  >>

From ptsfa!hoptoad!hugh Mon Jan  5 10:26:46 1987
Date: Mon, 5 Jan 87 01:22:17 PST
From: hoptoad!hugh (Hugh Daniel)
To: ptsfa!vixie!paul
Status: RO

  Hi, I do have a BIG one that I would like.  I want to log ALL output
from command lines into a file for each line.  Thus I might have a chance
of finding out why my crontab entry did not work.
  This would seem to work best if done by cron, as it is now I have a google
of shell scripts laying about just to put the error output where I can see
it.

<<	My cron (and the SysV cron) will send mail to the owner of the
	particular crontab file if a command generates any output on stdout
	or stderr.  This can be irritating, but if you write a script such
	that any output means a problem occurred, you can avoid most logfile
	needs, and not generate mail except in unforeseen circumstances.   >>

From ptsfa!dual!ucbvax!ihnp4!anvil!es!Robert_Toxen Mon Jan  5 13:08:46 1987
From: dual!ucbvax!ihnp4!anvil!es!Robert_Toxen
Date: Fri,  2 Jan 87 14:25:29 EST
To: anvil!ihnp4!ucbvax!dual!ptsfa!vixie!paul
Status: RO

Here are some suggestions:
1. Run it through the C preprocessor via "/lib/<whatever>".

<<	hmmm. this seems of limited utility, and if you really wanted
	to do it that way, you could do it yourself (since users can
	write to their own crontab files).  I'll add '-' (read stdin)
	to the crontab installer program to facilitate this.		>>

2. Allow specifying every Nth day of week, i.e., every second Wednesday.
   I did this to calendar by separating the day of week (Wed=4, which one
   to start on and N with slashes).  I took modulo the day of year as a
   starting point so that someone with a desk calendar documenting such
   things can easily determine the offset (second number).  I did this
   while at SGI; alas I don't have a copy of the code.

<<	I can see how this could be useful, but I'm not sure how I'd
	implement it.  Cron currently doesn't keep track of the last time
	a given command was run; whether the current Wednesday is the first
	or second since the command was last run would be pretty hard to
	figure out.  I'd have to keep a database of commands and their
	execution around, and purge it when the crontab was overwritten.
	This is too much work for me, but if someone adds it, let me know.  >>

From ptsfa!ames!seismo!cbmvax!devon!paul Tue Jan  6 05:50:17 1987
From: ames!seismo!cbmvax!devon!paul
To: cbmvax!seismo!nike!ptsfa!vixie!paul
Date: Mon Jan  5 09:29:57 1987
Status: RO

One problem that has always plagued me with cron is the assumed ORing.
I'd like to see some type of ANDing implemented.  I guess I can best
describe this by example.  Say I have the following line in my crontab
file:

*  *  4-31  *  1-6	/usr/bin/command

What this does is run 'command' on the 4th thru 31st days of the
month, AND on Monday thru Saturday; which probably means running it
every day of the month (unless Sunday falls on days 1-3).  This
happens because cron runs the command if the day-of-month OR the
day-of-week is true.

What I'd like to happen with the above line is to run the command ONLY
on Monday thru Saturday any time after the 3rd of the month, e.g. if
the day-of-month AND the day-of-week are true.

My proposal to you is to implement some special chars for the first
five fields.  Examples:

*  *  !1-3  *  1-6	/usr/bin/command

(run command Mon-Sat, but NOT [!] on the first 3 days of the month)

*  *  &4-31 *  &1-6	/usr/bin/command

(run command if day-of-month AND day-of-week are true)

Get the picture?  This would be compatable with existing versions of
cron (which wouldn't currently be using any special characters, so
that old crontabs would be handled correctly).

<<	This message made me aware of the actual boolean expression involved
	in a crontab entry.  I'd assumed that it was
		(minute && hour && DoM && month && DoW)
	But it's really
		(minute && hour && month && (DoM || DoW))

	I can see some value in changing this, but with a fixed order of
	fields, operators get to be kindof unary, which && and || really
	aren't.  If someone has an idea on a syntax that allows useful
	variations to the standard (&& && && (||)) default, please suggest. >>

From bobkat!pedz Tue Jan  6 20:02:10 1987
From: [e-mail] (Pedz Thing)
Date: 2 Jan 87 17:34:44 GMT
Status: RO

Log files!  It would be nice to be able to specify a log for cron
itself and also a log for each program's stdout and stderr to go to.
The latter can of course be done with > and 2> but it would be nice if
there could be a single line with some sort of pattern like
`> /usr/spool/log/%' and the command would be substituted for the %.
Another thing which would be nice is to be able to specify which shell
to call to give the command to.

<<	Log files are done with mail.  The '%' idea could be useful if
	a different character were used (% is special to cron, see man
	page); a different directory would have to be chosen, since each
	user has their own crontab file; and something intelligent would
	have to be done in the file naming, since the first word of the
	command might be ambiguous (with other commands).  In short, it's
	too much work.  Sorry.						  >>

From guy%gorodish@sun Tue Jan  6 20:03:13 1987
From: guy%gorodish@sun (Guy Harris)
Message-ID: <[e-mail]>
Date: 5 Jan 87 12:09:09 GMT
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Status: RO

> Another thing which would be nice is to be able to specify which shell
> to call to give the command to.

Well, the obvious choice would be the user's shell, but this wouldn't work
for accounts like "uucico".