Clean up deleted files.
This commit is contained in:
mycroft
parent
644d4f8787
commit
22183f4e79
@ -1,149 +0,0 @@
|
|||||||
Vixie Cron Changes from V2 to V3
|
|
||||||
Paul Vixie
|
|
||||||
29-Dec-1993
|
|
||||||
|
|
||||||
The crontab command now conforms to POSIX 1003.2. This means that when you
|
|
||||||
install it, if you have any "crontab" command lines floating around in shell
|
|
||||||
scripts (such as /etc/rc or /etc/rc.local), you will need to change them.
|
|
||||||
|
|
||||||
I have integrated several changes made by BSDi for their BSD/386 operating
|
|
||||||
system; these were offerred to me before I started consulting for them, so
|
|
||||||
it is safe to say that they were intended for publication. Most notably,
|
|
||||||
the name of the cron daemon has changed from "crond" to "cron". This was
|
|
||||||
done for compatibility with 4.3BSD. Another change made for the same reason
|
|
||||||
is the ability to read in an /etc/crontab file which has an extra field in
|
|
||||||
each entry, between the time fields and the command. This field is a user
|
|
||||||
name, and it permits the /etc/crontab command to contain commands which are
|
|
||||||
to be run by any user on the system. /etc/crontab is not "installed" via
|
|
||||||
the crontab(1) command; it is automatically read at startup time and it will
|
|
||||||
be reread whenever it changes.
|
|
||||||
|
|
||||||
I also added a "-e" option to crontab(1). Nine people also sent me diffs
|
|
||||||
to add this option, but I had already implemented it on my own. I actually
|
|
||||||
released an interrim version (V2.2, I think) for limited testing, and got a
|
|
||||||
chance to fix a bad security bug in the "-e" option thanks to XXX.
|
|
||||||
|
|
||||||
The daemon used to be extraordinarily sloppy in its use of file descriptors.
|
|
||||||
A heck of a lot of them were left open in spawned jobs, which caused problems
|
|
||||||
for the daemon and also caused problems with the spawned jobs if they were
|
|
||||||
shell scripts since "sh" and "csh" have traditionally used hidden file
|
|
||||||
descriptors to pass information to subshells, and cron was causing them to
|
|
||||||
think they were subshells. If you had trouble with "sh" or "csh" scripts in
|
|
||||||
V2, chances are good that V3 will fix your problems.
|
|
||||||
|
|
||||||
About a dozen people have reminded me that I forgot to initialize "crontab_fd"
|
|
||||||
in database.c. Keith Cantrell was the first, so he gets the point.
|
|
||||||
|
|
||||||
Steve Simmons reminded me that once an account has been deleted from the system,
|
|
||||||
"crontab -u USER -d" will not work. My solution is to suggest to all of you that
|
|
||||||
before you delete a user's account, you first delete that user's crontab file if
|
|
||||||
any. From cron's point of view, usernames can never be treated as arbitrary
|
|
||||||
strings. Either they are valid user names, or they are not. I will not make
|
|
||||||
an exception for the "-d" case, for security reasons that I consider reasonable.
|
|
||||||
It is trivial for a root user to delete the entry by hand if necessary.
|
|
||||||
|
|
||||||
Dan O'Neil reminded me that I forgot to reset "log_fd" in misc.c. A lot of others
|
|
||||||
also reminded me of this, but Dan gets the point. I didn't fix it there, since the
|
|
||||||
real bug was that it should have been open in the parent.
|
|
||||||
|
|
||||||
Peter Kabal reminded me that I forgot to "#ifdef DEBUGGING" some code in misc.c.
|
|
||||||
Hans Trompert actually told me first, but Peter sent the patch so he gets the point.
|
|
||||||
|
|
||||||
Russell Nelson told me that I'd forgotten to "#include <syslog.h>" in misc.c,
|
|
||||||
which explains why a lot of other people complained that it wasn't using syslog
|
|
||||||
even when they configured it that way :-). Steve Simmons told me first, though,
|
|
||||||
so he gets the point.
|
|
||||||
|
|
||||||
An interrim version of the daemon tried to "stat" every file before executing it;
|
|
||||||
this turned out to be a horribly bad idea since finding the name of a file from
|
|
||||||
a shell command is a hard job (that's why we have shells, right?) I removed this
|
|
||||||
bogus code. Dave Burgess gets the point.
|
|
||||||
|
|
||||||
Dennis R. Conley sent a suggestion for MMDF systems, which I've added to the
|
|
||||||
comments in cron.h.
|
|
||||||
|
|
||||||
Mike Heisler noted that I use comments in the CONVERSION file which are documented
|
|
||||||
as illegal in the man pages. Thanks, Mike.
|
|
||||||
|
|
||||||
Irving Wolfe sent me some very cheerful changes for a NeXT system, but I consider
|
|
||||||
the system itself broken and I can't bring myself to #ifdef for something as screwed
|
|
||||||
up as this system seems to be. Sorry, NeXT users -- pray for POSIX. Irving also
|
|
||||||
asked for a per-job MAILTO, but the syntactic overkill that would require is more
|
|
||||||
than I'm willing to add. Remember, on BSD4.2, cron was a 12K daemon. My cron is
|
|
||||||
about ten times that size already.
|
|
||||||
|
|
||||||
Lots of folks complained that the autogenerated "Date:" header wasn't in ARPA format.
|
|
||||||
I didn't understand this -- either folks will use Sendmail and not generate a Date:
|
|
||||||
at all (since Sendmail will do it), or folks will use something other than Sendmail
|
|
||||||
which won't care about Date: formats. But I've "fixed" it anyway...
|
|
||||||
|
|
||||||
Several people suggested that "*" should be able to take a "/step". One person
|
|
||||||
suggested that "N/step" ought to mean "N-last/step", but that's stretching things
|
|
||||||
a bit far. "*/step" seems quite intuitive to me, so I've added it. Colin Plumb
|
|
||||||
sent in the first and most polite request for this feature.
|
|
||||||
|
|
||||||
As with every release of Cron, BIND, and seemingly everything else I do, one
|
|
||||||
user stands out with the most critical but also the most useful analysis.
|
|
||||||
Cron V3's high score belongs to Peter Holzer, who sent in the nicest looking
|
|
||||||
patch for the "%" interpretation problem and also helped me understand a
|
|
||||||
tricky bit of badness in the "log_fd" problem.
|
|
||||||
|
|
||||||
agulbra@flode.nvg.unit.no wins the honors for being the first to point out the
|
|
||||||
nasty security hole in "crontab -r". 'Nuff said.
|
|
||||||
|
|
||||||
Several folks pointed out that log_it() needed to exist even if logging was
|
|
||||||
disabled. Some day I will create a tool that will compile a subsystem with
|
|
||||||
every possible combination and permutation of #ifdef options, but meanwhile
|
|
||||||
thanks to everybody.
|
|
||||||
|
|
||||||
job_runqueue() was using storage after freeing it, since Jordan told me back
|
|
||||||
in 1983 that C let you do that, and I believed him in 1986 when I wrote all
|
|
||||||
this junk. Linux was the first to die from this error, and the Linux people
|
|
||||||
sent me the most amazing, um, collection of patches for this problem. Thanks
|
|
||||||
for all the fish.
|
|
||||||
|
|
||||||
Jeremy Bettis reminded me that popen() isn't safe. I grabbed Ken Arnold's
|
|
||||||
version of popen/pclose from the ftpd and hacked it to taste. We're safe now,
|
|
||||||
from this at least.
|
|
||||||
|
|
||||||
Branko Lankester sent me a very timely and helpful fix for a looming security
|
|
||||||
problem in my "crontab -e" implementation.
|
|
||||||
|
|
||||||
--------
|
|
||||||
|
|
||||||
Vixie Cron Changes from V1 to V2
|
|
||||||
Paul Vixie
|
|
||||||
8-Feb-1988
|
|
||||||
|
|
||||||
Many changes were made in a rash of activity about six months ago, the exact
|
|
||||||
list of which is no longer clear in my memory. I know that V1 used a file
|
|
||||||
called POKECRON in /usr/spool/cron to tell it that it was time to re-read
|
|
||||||
all the crontab files; V2 uses the modtime the crontab directory as a flag to
|
|
||||||
check out the crontab files; those whose modtime has changed will be re-read,
|
|
||||||
and the others left alone. Note that the crontab(1) command will do a utimes
|
|
||||||
call to make sure the mtime of the dir changes, since the filename/inode will
|
|
||||||
often remain the same after a replacement and the mtime wouldn't change in
|
|
||||||
that case.
|
|
||||||
|
|
||||||
8-Feb-88: made it possible to use much larger environment variable strings.
|
|
||||||
V1 allowed 100 characters; V2 allows 1000. This was needed for PATH
|
|
||||||
variables on some systems. Thanks to Toerless Eckert for this idea.
|
|
||||||
E-mail: UUCP: ...pyramid!fauern!faui10!eckert
|
|
||||||
|
|
||||||
16-Feb-88: added allow/deny, moved /usr/spool/cron/crontabs to
|
|
||||||
/usr/lib/cron/tabs. allow and deny are /usr/lib/cron/{allow,deny},
|
|
||||||
since the sysv naming for this depends on 'at' using the same
|
|
||||||
dir, which would be stupid (hint: use /usr/{lib,spool}/at).
|
|
||||||
|
|
||||||
22-Feb-88: made it read the spool directory for crontabs and look each one
|
|
||||||
up using getpwnam() rather than reading all passwds with getpwent()
|
|
||||||
and trying to open each crontab.
|
|
||||||
|
|
||||||
9-Dec-88: made it sync to :00 after the minute, makes cron predictable.
|
|
||||||
added logging to /var/cron/log.
|
|
||||||
|
|
||||||
14-Apr-90: (actually, changes since December 1989)
|
|
||||||
fixed a number of bugs reported from the net and from John Gilmore.
|
|
||||||
added syslog per Keith Bostic. security features including not
|
|
||||||
being willing to run a command owned or writable by other than
|
|
||||||
the owner of the crontab 9not working well yet)
|
|
||||||
@ -1,85 +0,0 @@
|
|||||||
$Id: CONVERSION,v 1.1.1.1 1994/01/05 20:40:12 jtc Exp $
|
|
||||||
|
|
||||||
Conversion of BSD 4.[23] crontab files:
|
|
||||||
|
|
||||||
Edit your current crontab (/usr/lib/crontab) into little pieces, with each
|
|
||||||
users' commands in a different file. This is different on 4.2 and 4.3,
|
|
||||||
but I'll get to that below. The biggest feature of this cron is that you
|
|
||||||
can move 'news' and 'uucp' cron commands into files owned and maintainable
|
|
||||||
by those two users. You also get to rip all the fancy 'su' footwork out
|
|
||||||
of the cron commands. On 4.3, there's no need for the 'su' stuff since the
|
|
||||||
user name appears on each command -- but I'd still rather have separate
|
|
||||||
crontabs with seperate environments and so on.
|
|
||||||
|
|
||||||
Leave the original /usr/lib/crontab! This cron doesn't use it, so you may
|
|
||||||
as well keep it around for a while in case something goes wakko with this
|
|
||||||
fancy version.
|
|
||||||
|
|
||||||
Most commands in most crontabs are run by root, have to run by root, and
|
|
||||||
should continue to be run by root. They still have to be in their own file;
|
|
||||||
I recommend /etc/crontab.src or /usr/adm/crontab.src.
|
|
||||||
|
|
||||||
'uucp's commands need their own file; how about /usr/lib/uucp/crontab.src?
|
|
||||||
'news' also, perhaps in /usr/lib/news/crontab.src...
|
|
||||||
|
|
||||||
I say `how about' and `perhaps' because it really doesn't matter to anyone
|
|
||||||
(except you) where you put the crontab source files. The `crontab' command
|
|
||||||
COPIES them into a protected directory (CRONDIR/SPOOL_DIR in cron.h), named
|
|
||||||
after the user whose crontab it is. If you want to examine, replace, or
|
|
||||||
delete a crontab, the `crontab' command does all of those things. The
|
|
||||||
various `crontab.src' (my suggested name for them) files are just source
|
|
||||||
files---they have to be copied to SPOOLDIR using `crontab' before they'll be
|
|
||||||
executed.
|
|
||||||
|
|
||||||
On 4.2, your crontab might have a few lines like this:
|
|
||||||
|
|
||||||
5 * * * * su uucp < /usr/lib/uucp/uudemon.hr
|
|
||||||
10 4 * * * su uucp < /usr/lib/uucp/uudemon.day
|
|
||||||
15 5 * * 0 su uucp < /usr/lib/uucp/uudemon.wk
|
|
||||||
|
|
||||||
...or like this:
|
|
||||||
|
|
||||||
5 * * * * echo /usr/lib/uucp/uudemon.hr | su uucp
|
|
||||||
10 4 * * * echo /usr/lib/uucp/uudemon.day | su uucp
|
|
||||||
15 5 * * 0 echo /usr/lib/uucp/uudemon.wk | su uucp
|
|
||||||
|
|
||||||
On 4.3, they'd look a little bit better, but not much:
|
|
||||||
|
|
||||||
5 * * * * uucp /usr/lib/uucp/uudemon.hr
|
|
||||||
10 4 * * * uucp /usr/lib/uucp/uudemon.day
|
|
||||||
15 5 * * 0 uucp /usr/lib/uucp/uudemon.wk
|
|
||||||
|
|
||||||
For this cron, you'd create /usr/lib/uucp/crontab.src (or wherever you want
|
|
||||||
to keep uucp's commands) which would look like this:
|
|
||||||
|
|
||||||
# /usr/lib/uucp/crontab.src - uucp's crontab
|
|
||||||
#
|
|
||||||
PATH=/usr/lib/uucp:/bin:/usr/bin
|
|
||||||
SHELL=/bin/sh
|
|
||||||
HOME=/usr/lib/uucp
|
|
||||||
#
|
|
||||||
5 * * * * uudemon.hr
|
|
||||||
10 4 * * * uudemon.day
|
|
||||||
15 5 * * 0 uudemon.wk
|
|
||||||
|
|
||||||
The application to the `news' cron commands (if any) is left for you to
|
|
||||||
figure out. Likewise if there are any other cruddy-looking 'su' commands in
|
|
||||||
your crontab commands, you don't need them anymore: just find a good place
|
|
||||||
to put the `crontab.src' (or whatever you want to call it) file for that
|
|
||||||
user, put the cron commands into it, and install it using the `crontab'
|
|
||||||
command (probably with "-u USERNAME", but see the man page).
|
|
||||||
|
|
||||||
If you run a 4.2-derived cron, you could of course just install your current
|
|
||||||
crontab in toto as root's crontab. It would work exactly the way your
|
|
||||||
current one does, barring the extra steps in installing or changing it.
|
|
||||||
There would still be advantages to this cron, mostly that you get mail if
|
|
||||||
there is any output from your cron commands.
|
|
||||||
|
|
||||||
One note about getting mail from cron: you will probably find, after you
|
|
||||||
install this version of cron, that your cron commands are generating a lot
|
|
||||||
of irritating output. The work-around for this is to redirect all EXPECTED
|
|
||||||
output to a per-execution log file, which you can examine if you want to
|
|
||||||
see the output from the "last time" a command was executed; if you get any
|
|
||||||
UNEXPECTED output, it will be mailed to you. This takes a while to get
|
|
||||||
right, but it's amazingly convenient. Trust me.
|
|
||||||
|
|
||||||
@ -1,88 +0,0 @@
|
|||||||
$Id: FEATURES,v 1.1.1.1 1994/01/05 20:40:12 jtc 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,475 +0,0 @@
|
|||||||
[ 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.1.1 1994/01/05 20:40:12 jtc 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: pedz@bobkat.UUCP (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: <10944@sun.uucp>
|
|
||||||
Date: 5 Jan 87 12:09:09 GMT
|
|
||||||
References: <429@vixie.UUCP> <359@bobkat.UUCP>
|
|
||||||
Sender: news@sun.uucp
|
|
||||||
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".
|
|
||||||
|
|
||||||
<< I use the owning user's shell, and to handle "uucico" I check a
|
|
||||||
list of "acceptable shells" (currently compiled in, does anybody
|
|
||||||
mind?), substituting a default (compiled in) shell if the user's
|
|
||||||
shell isn't on the list.
|
|
||||||
|
|
||||||
BTW, "compiled in" means that it's in a .h file, easily changed
|
|
||||||
during installation, but requiring recompilation to modify. You
|
|
||||||
don't have to go digging through the code to find it... >>
|
|
||||||
|
|
||||||
From qantel!hplabs!ucbvax!mwm@violet.berkeley.edu Tue Jan 6 21:24:48 1987
|
|
||||||
To: hplabs!qantel!vixie!paul (Paul Vixie Esq)
|
|
||||||
Date: 04 Jan 87 00:42:35 PST (Sun)
|
|
||||||
From: Mike Meyer <mwm@violet.berkeley.edu>
|
|
||||||
Status: RO
|
|
||||||
|
|
||||||
<<[Discussion of RMS/FSF, and mwm's GNU Cron deleted]>>
|
|
||||||
|
|
||||||
Oh, yeah - here are the extensions on my cron:
|
|
||||||
|
|
||||||
1) Sunday is both day 0 and day 7, so it complies with both SysV and
|
|
||||||
BSD cron.
|
|
||||||
|
|
||||||
<< Good idea. I did it too, thanks for informing me. >>
|
|
||||||
|
|
||||||
2) At is integrated into the cron. Instead of atrun to scan the
|
|
||||||
/usr/spool/at directory, at files are put into the /usr/lib/cron
|
|
||||||
directory along with users cron files, and cron fabricates a line from
|
|
||||||
a crontab file to run them. This is considered a major win by all who
|
|
||||||
use it.
|
|
||||||
|
|
||||||
<< I don't use 'at', and my cron doesn't do anything with it. To run
|
|
||||||
'at', I use 'atrun' the same way the current BSD cron does. My
|
|
||||||
crontab files are in /usr/spool/cron/crontabs, in the SysV
|
|
||||||
tradition -- not in /usr/lib/cron. This is a configuration
|
|
||||||
parameter, of course. >>
|
|
||||||
|
|
||||||
There are two known restrictions:
|
|
||||||
|
|
||||||
1) I don't support any of the SysV security hooks. I don't have a use
|
|
||||||
for them, and RMS didn't like the idea at all :-).
|
|
||||||
|
|
||||||
<< This means cron.allow and cron.deny. I plan to support them, as
|
|
||||||
they've been quite helpful at various HPUX sites I've administered. >>
|
|
||||||
|
|
||||||
2) Cron expects to be able to create files with names longer than 14
|
|
||||||
characters, which makes it hard to run on SysV. At least one person
|
|
||||||
was working on a port, but I don't know how it's going. That might
|
|
||||||
make for a good reason for releasing yours, right there.
|
|
||||||
|
|
||||||
<< If someone has SysV (with the 14-character limit), they probably
|
|
||||||
won't want my cron, since it doesn't add much to the standard
|
|
||||||
version (which they may have support for). My cron is not currently
|
|
||||||
portable to non-BSD systems, since it relies on interval timers (I
|
|
||||||
needed to sleep for intervals more granular than seconds alone would
|
|
||||||
allow). The port would be trivial, and I will do it if a lot of
|
|
||||||
people ask for it... >>
|
|
||||||
|
|
||||||
Oh, yeah - I'm going to see about getting this cron integrated into
|
|
||||||
the next 4BSD release.
|
|
||||||
|
|
||||||
<< How does one go about this? I have a few nifty gadgets I'd like
|
|
||||||
to contribute, this cron being one of them... >>
|
|
||||||
|
|
||||||
<<[more FSF/GNU discussion deleted]>>
|
|
||||||
|
|
||||||
From qantel!hplabs!ames!ut-sally!ut-ngp!melpad!bigtex!james Tue Jan 6 21:24:57 1987
|
|
||||||
Posted-Date: Fri, 2 Jan 87 19:26:16 est
|
|
||||||
Date: Fri, 2 Jan 87 19:26:16 est
|
|
||||||
From: hplabs!ames!ut-sally!ut-ngp!bigtex!james
|
|
||||||
To: vixie!paul
|
|
||||||
Status: RO
|
|
||||||
|
|
||||||
Yes!!! There are several critical failures in System V cron...
|
|
||||||
|
|
||||||
1. Pass all variables in cron's environment into the environment of things
|
|
||||||
cron starts up, or at least into the crontab entries started up (at jobs
|
|
||||||
will inherit the environment of the user). If nothing else it is critically
|
|
||||||
important that the TZ variable be passed on. PATH should be passed on too.
|
|
||||||
Basically, passing environment values allows one to design a standard
|
|
||||||
environment with TZ and PATH and have that run by everything. If anyone
|
|
||||||
tells you this is no big deal, consider what happens when uucico is
|
|
||||||
started by cron in CA to make a long distance phone link... Unless the
|
|
||||||
administrator is really on his/her toes, calls scheduled at 5pm will really
|
|
||||||
go at two in the afternoon, needlessly incurring huge phone bills, all
|
|
||||||
because System V refuses to pass the TZ from its environment down. There
|
|
||||||
are work arounds, but only putting it in cron will really work. This is
|
|
||||||
not a security hole.
|
|
||||||
|
|
||||||
<< delete TERM and TERMCAP; modify HOME, USER, and CWD; pass TZ and
|
|
||||||
PATH through undisturbed. any other requests out there?
|
|
||||||
|
|
||||||
BSD doesn't have this problem -- TZ is passed right on through if
|
|
||||||
you define it in the shell before starting my cron daemon. However,
|
|
||||||
the BSD I'm running this on doesn't need TZ to be defined anyway...
|
|
||||||
The default in the kernel has been just fine so far... But just the
|
|
||||||
same, if/when I port to SysV (I guess I really should), I'll make
|
|
||||||
sure this works right.
|
|
||||||
|
|
||||||
I guess I've been spoiled. HPUX is SysV-based, and I never had a
|
|
||||||
problem with cron and TZ when I used it. >>
|
|
||||||
|
|
||||||
2. A way to avoid logging stuff in /usr/lib/cron/log. I have a cron entry
|
|
||||||
run uudemon.hr every 10 minutes. This is 144 times/day. Each run generates
|
|
||||||
three lines of text, for a total of 432 lines of text I don't want to see.
|
|
||||||
Obviously this should be optional, but it would be nice if there were a
|
|
||||||
way to flag an entry so that it wasn't logged at all unless there was an
|
|
||||||
error.
|
|
||||||
|
|
||||||
<< I don't know nothin' 'bout no /usr/lib/cron/log. What is this file?
|
|
||||||
I don't see any reason to create log entries, given the mail-the-
|
|
||||||
output behaviour. Opinions, anyone? >>
|
|
||||||
|
|
||||||
I will come up with other ideas no doubt, but I can always implement them
|
|
||||||
myself.
|
|
||||||
|
|
||||||
<< That's what I like about PD software. Please send me the diffs! >>
|
|
||||||
|
|
||||||
The other problem you have is making sure you can run standard
|
|
||||||
crontabs. I would suggest something like this: if the command part of the
|
|
||||||
entry starts with an unescaped -, then flags and options follow immediately
|
|
||||||
thereafter. As in:
|
|
||||||
|
|
||||||
2,12,22,32,42,52 * * * * -q /usr/lib/uucp/uudemon.hr
|
|
||||||
|
|
||||||
This could mean do not log the uudemon.hr run unless there is a problem of
|
|
||||||
some kind. This is probably safe as not many filenames start with "-", and
|
|
||||||
those that do are already a problem for people.
|
|
||||||
|
|
||||||
<< Since I don't plan on supporting /usr/lib/cron/log in ANY form unless
|
|
||||||
many people request it, I won't be needing -q as you've defined it.
|
|
||||||
I could use something like this to avoid sending mail on errors, for
|
|
||||||
the occasional script that you don't want to bullet-proof.
|
|
||||||
|
|
||||||
The compatibility issue is CRITICAL. The 4.3BSD crontab format is
|
|
||||||
a crime against the whole philosophy of Unix(TM), in my opinion. >>
|
|
||||||
|
|
||||||
One other minor thing to consider is the ulimit: can different users get
|
|
||||||
different ulimits for their crontab entries?
|
|
||||||
|
|
||||||
<< Boy I'm ignorant today. What's a ulimit, and what should I do with
|
|
||||||
it in a crontab? Suggestions, enlightenment, etc ?? >>
|
|
||||||
|
|
||||||
From qantel!lll-crg!ames!uw-beaver!uw-nsr!john Tue Jan 6 23:32:44 1987
|
|
||||||
Date: Thu, 1 Jan 87 10:53:05 pst
|
|
||||||
From: lll-crg!ames!uw-beaver!uw-nsr!john (John Sambrook 5-7433)
|
|
||||||
To: vixie!paul
|
|
||||||
Status: RO
|
|
||||||
|
|
||||||
How about not hardwiring the default environment that cron builds for its
|
|
||||||
children in the cron program itself? Our cron does this and it's the pits
|
|
||||||
because we are TZ=PST8PDT not TZ=EST5EDT !
|
|
||||||
|
|
||||||
<< yeachk. I assure you, I will not hardwire the TZ! >>
|
|
||||||
From ptsfa!well!dv Fri Jan 9 04:01:50 1987
|
|
||||||
Date: Thu, 8 Jan 87 23:50:40 pst
|
|
||||||
From: well!dv (David W. Vezie)
|
|
||||||
To: ptsfa!vixie!paul
|
|
||||||
Status: RO
|
|
||||||
|
|
||||||
6, have a special notation called 'H' which would expand to weekends
|
|
||||||
and holidays (you'd have to keep a database somewhere of real
|
|
||||||
holidays), and also 'W' for workdays (neither weekend or holiday).
|
|
||||||
|
|
||||||
<< Too much work. There should be a standard way to define and
|
|
||||||
detect holidays under Unix(TM); if there were, I'd use it. As
|
|
||||||
it is, I'll leave this for someone else to add.
|
|
||||||
|
|
||||||
I can see the usefulness; it just doesn't quite seem worth it. >>
|
|
||||||
From qantel!gatech!akgua!blnt1!jat Wed Jan 14 20:00:40 1987
|
|
||||||
Date: Tue, 13 Jan 87 16:39:38 EST
|
|
||||||
From: gatech!akgua!blnt1!jat
|
|
||||||
Status: RO
|
|
||||||
|
|
||||||
1) Add some way to tell cron to reread the files, say kill -1 <pid>
|
|
||||||
|
|
||||||
<< whenever the 'crontab' program is run and updates a crontab file,
|
|
||||||
a file /usr/spool/cron/POKECRON is created; next time the cron
|
|
||||||
daemon wakes up, it sees it, and re-reads the crontab files.
|
|
||||||
|
|
||||||
I thought of handling the signal; even implemented it. Then this
|
|
||||||
clever idea hit me and I ripped it all out and added a single
|
|
||||||
IF-statement to handle the POKECRON file. >>
|
|
||||||
|
|
||||||
2) Have some kind of retry time so that if a command fails, cron will try to
|
|
||||||
execute it again after a certain period. This is useful if you have some
|
|
||||||
type of cleanup program that can run at the scheduled time for some reason
|
|
||||||
(such as locked device, unmounted filesystem, etc).
|
|
||||||
|
|
||||||
<< Hmmm, sounds useful. I could do this by submitting an 'at' job...
|
|
||||||
I'll think about it. >>
|
|
||||||
From ptsfa!dual!ucbvax!ihnp4!mtuxo!ender Sat Jan 3 16:54:00 1987
|
|
||||||
From: dual!ucbvax!ihnp4!mtuxo!ender
|
|
||||||
Date: Sat, 3 Jan 87 14:05:13 PST
|
|
||||||
To: ucbvax!dual!ptsfa!vixie!paul
|
|
||||||
Status: RO
|
|
||||||
|
|
||||||
It would be nice if nonprivileged users can setup personal crontab files
|
|
||||||
(~/.cronrc, say) and be able to run personal jobs at regular intervals.
|
|
||||||
|
|
||||||
<< this is done, but in the SysV style: the 'crontab' program installs
|
|
||||||
a new crontab file for the executing user (can be overridden by root
|
|
||||||
for setup of uucp and news). the advantage of this is that (1) when
|
|
||||||
a crontab is changed, the daemon can be informed automatically; and
|
|
||||||
(2) the file can be syntax-checked before installation. >>
|
|
||||||
From ptsfa!ames!seismo!ihnp4!lcc!richard Fri Jan 16 04:47:33 1987
|
|
||||||
Date: Fri, 16 Jan 87 07:44:57 EST
|
|
||||||
To: nike!ptsfa!vixie!paul
|
|
||||||
Status: RO
|
|
||||||
|
|
||||||
The System V cron is nice, but it has a few annoying features. One is that
|
|
||||||
its mail files will say that the previous message is the output of "one of your
|
|
||||||
cron commands." I wish it would say WHICH cron commmand.
|
|
||||||
|
|
||||||
<< Done. Also which shell, which user (useful when the mail gets
|
|
||||||
forwarded), which home directory, and other useful crud. >>
|
|
||||||
|
|
||||||
Another problem is with timezones. It is necessary to specify TZ=PST8PDT (or
|
|
||||||
whatever) when you invoke cron (from inittab, or /etc/rc) and it is also
|
|
||||||
necessary to add TZ=PST8PDT to each crontab line which might need it. Cron
|
|
||||||
should automatically export its idea of the "TZ" to each invoked command, and
|
|
||||||
it should be possible to put a line in the crontab file which overrides that
|
|
||||||
for every command in the file (e.g., most users are on EST, so cron is run
|
|
||||||
with TZ=EST5EDT; but one user is usually on PST and wants all of his cron
|
|
||||||
commands to run with TZ=PST8PDT). This might be extended to allow any
|
|
||||||
environment variable to be specified once for the whole crontab file (e.g.,
|
|
||||||
PATH).
|
|
||||||
|
|
||||||
<< Well, since I run the user's shell, you could put this into .cshrc.
|
|
||||||
generic environment-variable setting could be useful, though. Since
|
|
||||||
I have to modify the environment anyway, I'll consider this. >>
|
|
||||||
|
|
||||||
A log file might be a nice idea, but the System V cron log is too verbose.
|
|
||||||
I seem to remember that cron keeps it open, too; so you can't even have
|
|
||||||
something go and periodically clean it out.
|
|
||||||
|
|
||||||
<< I don't do /usr/lib/cron/log. I wasn't aware of this file until I
|
|
||||||
got all these suggestions. Do people want this file? Tell me! >>
|
|
||||||
@ -1,30 +0,0 @@
|
|||||||
File Name Archive # Description
|
|
||||||
-----------------------------------------------------------
|
|
||||||
CHANGES 1
|
|
||||||
CONVERSION 1
|
|
||||||
FEATURES 1
|
|
||||||
INSTALL 1
|
|
||||||
MAIL 2
|
|
||||||
MANIFEST 1 This shipping list
|
|
||||||
Makefile 1
|
|
||||||
README 1
|
|
||||||
THANKS 1
|
|
||||||
bitstring.3 1
|
|
||||||
bitstring.h 1
|
|
||||||
config.h 1
|
|
||||||
cron.8 1
|
|
||||||
cron.c 1
|
|
||||||
cron.h 1
|
|
||||||
crontab.1 1
|
|
||||||
crontab.5 1
|
|
||||||
crontab.c 2
|
|
||||||
database.c 1
|
|
||||||
do_command.c 2
|
|
||||||
entry.c 2
|
|
||||||
env.c 1
|
|
||||||
externs.h 1
|
|
||||||
job.c 1
|
|
||||||
misc.c 2
|
|
||||||
pathnames.h 1
|
|
||||||
popen.c 1
|
|
||||||
user.c 1
|
|
||||||
@ -1,72 +0,0 @@
|
|||||||
#/* Copyright 1988,1990,1993 by Paul Vixie
|
|
||||||
# * All rights reserved
|
|
||||||
# *
|
|
||||||
# * Distribute freely, except: don't remove my name from the source or
|
|
||||||
# * documentation (don't take credit for my work), mark your changes (don't
|
|
||||||
# * get me blamed for your possible bugs), don't alter or remove this
|
|
||||||
# * notice. May be sold if buildable source is provided to buyer. No
|
|
||||||
# * warrantee of any kind, express or implied, is included with this
|
|
||||||
# * software; use at your own risk, responsibility for damages (if any) to
|
|
||||||
# * anyone resulting from the use of this software rests entirely with the
|
|
||||||
# * user.
|
|
||||||
# *
|
|
||||||
# * Send bug reports, bug fixes, enhancements, requests, flames, etc., and
|
|
||||||
# * I'll try to keep a version up to date. I can be reached as follows:
|
|
||||||
# * Paul Vixie <paul@vix.com> uunet!decwrl!vixie!paul
|
|
||||||
# */
|
|
||||||
|
|
||||||
Vixie Cron V3.0
|
|
||||||
December 27, 1993
|
|
||||||
[V2.2 was some time in 1992]
|
|
||||||
[V2.1 was May 29, 1991]
|
|
||||||
[V2.0 was July 5, 1990]
|
|
||||||
[V2.0-beta was December 9, 1988]
|
|
||||||
[V1.0 was May 6, 1987]
|
|
||||||
Paul Vixie
|
|
||||||
|
|
||||||
This is a version of 'cron' that is known to run on BSD 4.[23] systems. It
|
|
||||||
is functionally based on the SysV cron, which means that each user can have
|
|
||||||
their own crontab file (all crontab files are stored in a read-protected
|
|
||||||
directory, usually /var/cron/tabs). No direct support is provided for
|
|
||||||
'at'; you can continue to run 'atrun' from the crontab as you have been
|
|
||||||
doing. If you don't have atrun (i.e., System V) you are in trouble.
|
|
||||||
|
|
||||||
A messages is logged each time a command is executed; also, the files
|
|
||||||
"allow" and "deny" in /var/cron can be used to control access to the
|
|
||||||
"crontab" command (which installs crontabs). It hasn't been tested on
|
|
||||||
SysV, although some effort has gone into making the port an easy one.
|
|
||||||
|
|
||||||
This is more or less the copyright that USENET contributed software usually
|
|
||||||
has. Since ATT couldn't use this version if they had to freely distribute
|
|
||||||
source, and since I'd love to see them use it, I'll offer some rediculously
|
|
||||||
low license fee just to have them take it. In the unlikely event that they
|
|
||||||
do this, I will continue to support and distribute the pseudo-PD version, so
|
|
||||||
please, don't flame me for wanting my work to see a wider distribution.
|
|
||||||
|
|
||||||
To use this: Sorry, folks, there is no cutesy 'Configure' script. You'll
|
|
||||||
have to go edit a couple of files... So, here's the checklist:
|
|
||||||
|
|
||||||
Read all the FEATURES, INSTALL, and CONVERSION files
|
|
||||||
Edit config.h
|
|
||||||
Edit Makefile
|
|
||||||
(both of these files have instructions inside; note that
|
|
||||||
some things in config.h are definable in Makefile and are
|
|
||||||
therefore surrounded by #ifndef...#endif)
|
|
||||||
'make'
|
|
||||||
'su' and 'make install'
|
|
||||||
(you may have to install the man pages by hand)
|
|
||||||
kill your existing cron process
|
|
||||||
(actually you can run your existing cron if you want, but why?)
|
|
||||||
build new crontabs using /usr/lib/{crontab,crontab.local}
|
|
||||||
(either put them all in "root"'s crontab, or divide it up
|
|
||||||
and rip out all the 'su' commands, collapse the lengthy
|
|
||||||
lists into ranges with steps -- basically, this step is
|
|
||||||
as much work as you want to make it)
|
|
||||||
start up the new cron
|
|
||||||
(must be done as root)
|
|
||||||
watch it. test it with 'crontab -r' and watch the daemon track your
|
|
||||||
changes.
|
|
||||||
if you like it, change your /etc/{rc,rc.local} to use it instead of
|
|
||||||
the old one.
|
|
||||||
|
|
||||||
$Id: README,v 1.1.1.1 1994/01/05 20:40:12 jtc Exp $
|
|
||||||
@ -1,168 +0,0 @@
|
|||||||
.\" Copyright (c) 1989 The Regents of the University of California.
|
|
||||||
.\" All rights reserved.
|
|
||||||
.\"
|
|
||||||
.\" This code is derived from software contributed to Berkeley by
|
|
||||||
.\" Paul Vixie.
|
|
||||||
.\"
|
|
||||||
.\" Redistribution and use in source and binary forms are permitted
|
|
||||||
.\" provided that the above copyright notice and this paragraph are
|
|
||||||
.\" duplicated in all such forms and that any documentation,
|
|
||||||
.\" advertising materials, and other materials related to such
|
|
||||||
.\" distribution and use acknowledge that the software was developed
|
|
||||||
.\" by the University of California, Berkeley. The name of the
|
|
||||||
.\" University may not be used to endorse or promote products derived
|
|
||||||
.\" from this software without specific prior written permission.
|
|
||||||
.\" THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR
|
|
||||||
.\" IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
|
|
||||||
.\" WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
|
|
||||||
.\"
|
|
||||||
.\" @(#)bitstring.3 5.1 (Berkeley) 12/13/89
|
|
||||||
.\"
|
|
||||||
.TH BITSTRING 3 "December 13, 1989"
|
|
||||||
.UC 4
|
|
||||||
.SH NAME
|
|
||||||
bit_alloc, bit_clear, bit_decl, bit_ffs, bit_nclear, bit_nset,
|
|
||||||
bit_set, bitstr_size, bit_test \- bit-string manipulation macros
|
|
||||||
.SH SYNOPSIS
|
|
||||||
.ft B
|
|
||||||
.nf
|
|
||||||
#include <bitstring.h>
|
|
||||||
|
|
||||||
name = bit_alloc(nbits)
|
|
||||||
bitstr_t *name;
|
|
||||||
int nbits;
|
|
||||||
|
|
||||||
bit_decl(name, nbits)
|
|
||||||
bitstr_t name;
|
|
||||||
int nbits;
|
|
||||||
|
|
||||||
bit_clear(name, bit)
|
|
||||||
bitstr_t name;
|
|
||||||
int bit;
|
|
||||||
|
|
||||||
bit_ffc(name, nbits, value)
|
|
||||||
bitstr_t name;
|
|
||||||
int nbits, *value;
|
|
||||||
|
|
||||||
bit_ffs(name, nbits, value)
|
|
||||||
bitstr_t name;
|
|
||||||
int nbits, *value;
|
|
||||||
|
|
||||||
bit_nclear(name, start, stop)
|
|
||||||
bitstr_t name;
|
|
||||||
int start, stop;
|
|
||||||
|
|
||||||
bit_nset(name, start, stop)
|
|
||||||
bitstr_t name;
|
|
||||||
int start, stop;
|
|
||||||
|
|
||||||
bit_set(name, bit)
|
|
||||||
bitstr_t name;
|
|
||||||
int bit;
|
|
||||||
|
|
||||||
bitstr_size(nbits)
|
|
||||||
int nbits;
|
|
||||||
|
|
||||||
bit_test(name, bit)
|
|
||||||
bitstr_t name;
|
|
||||||
int bit;
|
|
||||||
.fi
|
|
||||||
.ft R
|
|
||||||
.SH DESCRIPTION
|
|
||||||
These macros operate on strings of bits.
|
|
||||||
.PP
|
|
||||||
.I Bit_alloc
|
|
||||||
returns a pointer of type
|
|
||||||
.I bitstr_t\ *
|
|
||||||
to sufficient space to store
|
|
||||||
.I nbits
|
|
||||||
bits, or NULL if no space is available.
|
|
||||||
.PP
|
|
||||||
.I Bit_decl
|
|
||||||
is a macro for allocating sufficient space to store
|
|
||||||
.I nbits
|
|
||||||
bits on the stack.
|
|
||||||
.PP
|
|
||||||
.I Bitstr_size
|
|
||||||
returns the number of elements of type
|
|
||||||
.I bitstr_t
|
|
||||||
necessary to store
|
|
||||||
.I nbits
|
|
||||||
bits.
|
|
||||||
This is useful for copying bit strings.
|
|
||||||
.PP
|
|
||||||
.I Bit_clear
|
|
||||||
and
|
|
||||||
.I bit_set
|
|
||||||
clear or set the zero-based numbered bit
|
|
||||||
.IR bit ,
|
|
||||||
in the bit string
|
|
||||||
.IR name .
|
|
||||||
.PP
|
|
||||||
.I Bit_nset
|
|
||||||
and
|
|
||||||
.I bit_nclear
|
|
||||||
set or clear the zero-based numbered bits from
|
|
||||||
.I start
|
|
||||||
to
|
|
||||||
.I stop
|
|
||||||
in the bit string
|
|
||||||
.IR name .
|
|
||||||
.PP
|
|
||||||
.I Bit_test
|
|
||||||
evaluates to zero if the zero-based numbered bit
|
|
||||||
.I bit
|
|
||||||
of bit string
|
|
||||||
.I name
|
|
||||||
is set, and non-zero otherwise.
|
|
||||||
.PP
|
|
||||||
.I Bit_ffs
|
|
||||||
sets
|
|
||||||
.I *value
|
|
||||||
to the zero-based number of the first bit set in the array of
|
|
||||||
.I nbits
|
|
||||||
bits referenced by
|
|
||||||
.IR name .
|
|
||||||
If no bits are set,
|
|
||||||
.I *value
|
|
||||||
is set to -1.
|
|
||||||
.PP
|
|
||||||
.I Bit_ffc
|
|
||||||
sets
|
|
||||||
.I *value
|
|
||||||
to the zero-based number of the first bit not set in the array of
|
|
||||||
.I nbits
|
|
||||||
bits referenced by
|
|
||||||
.IR name .
|
|
||||||
If all bits are set,
|
|
||||||
.I value
|
|
||||||
is set to -1.
|
|
||||||
.SH EXAMPLE
|
|
||||||
.nf
|
|
||||||
.in +5
|
|
||||||
#include <limits.h>
|
|
||||||
#include <bitstring.h>
|
|
||||||
|
|
||||||
...
|
|
||||||
#define LPR_BUSY_BIT 0
|
|
||||||
#define LPR_FORMAT_BIT 1
|
|
||||||
#define LPR_DOWNLOAD_BIT 2
|
|
||||||
...
|
|
||||||
#define LPR_AVAILABLE_BIT 9
|
|
||||||
#define LPR_MAX_BITS 10
|
|
||||||
|
|
||||||
make_lpr_available()
|
|
||||||
{
|
|
||||||
bitstr_t bit_decl(bitlist, LPR_MAX_BITS);
|
|
||||||
...
|
|
||||||
bit_nclear(bitlist, 0, LPR_MAX_BITS - 1);
|
|
||||||
...
|
|
||||||
if (!bit_test(bitlist, LPR_BUSY_BIT)) {
|
|
||||||
bit_clear(bitlist, LPR_FORMAT_BIT);
|
|
||||||
bit_clear(bitlist, LPR_DOWNLOAD_BIT);
|
|
||||||
bit_set(bitlist, LPR_AVAILABLE_BIT);
|
|
||||||
}
|
|
||||||
}
|
|
||||||
.fi
|
|
||||||
.SH "SEE ALSO"
|
|
||||||
malloc(3)
|
|
||||||
@ -1,122 +0,0 @@
|
|||||||
/*
|
|
||||||
* Copyright (c) 1989 The Regents of the University of California.
|
|
||||||
* All rights reserved.
|
|
||||||
*
|
|
||||||
* This code is derived from software contributed to Berkeley by
|
|
||||||
* Paul Vixie.
|
|
||||||
*
|
|
||||||
* Redistribution and use in source and binary forms are permitted
|
|
||||||
* provided that the above copyright notice and this paragraph are
|
|
||||||
* duplicated in all such forms and that any documentation,
|
|
||||||
* advertising materials, and other materials related to such
|
|
||||||
* distribution and use acknowledge that the software was developed
|
|
||||||
* by the University of California, Berkeley. The name of the
|
|
||||||
* University may not be used to endorse or promote products derived
|
|
||||||
* from this software without specific prior written permission.
|
|
||||||
* THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR
|
|
||||||
* IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
|
|
||||||
* WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
|
|
||||||
*
|
|
||||||
* @(#)bitstring.h 5.2 (Berkeley) 4/4/90
|
|
||||||
*/
|
|
||||||
|
|
||||||
typedef unsigned char bitstr_t;
|
|
||||||
|
|
||||||
/* internal macros */
|
|
||||||
/* byte of the bitstring bit is in */
|
|
||||||
#define _bit_byte(bit) \
|
|
||||||
((bit) >> 3)
|
|
||||||
|
|
||||||
/* mask for the bit within its byte */
|
|
||||||
#define _bit_mask(bit) \
|
|
||||||
(1 << ((bit)&0x7))
|
|
||||||
|
|
||||||
/* external macros */
|
|
||||||
/* bytes in a bitstring of nbits bits */
|
|
||||||
#define bitstr_size(nbits) \
|
|
||||||
((((nbits) - 1) >> 3) + 1)
|
|
||||||
|
|
||||||
/* allocate a bitstring */
|
|
||||||
#define bit_alloc(nbits) \
|
|
||||||
(bitstr_t *)malloc(1, \
|
|
||||||
(unsigned int)bitstr_size(nbits) * sizeof(bitstr_t))
|
|
||||||
|
|
||||||
/* allocate a bitstring on the stack */
|
|
||||||
#define bit_decl(name, nbits) \
|
|
||||||
(name)[bitstr_size(nbits)]
|
|
||||||
|
|
||||||
/* is bit N of bitstring name set? */
|
|
||||||
#define bit_test(name, bit) \
|
|
||||||
((name)[_bit_byte(bit)] & _bit_mask(bit))
|
|
||||||
|
|
||||||
/* set bit N of bitstring name */
|
|
||||||
#define bit_set(name, bit) \
|
|
||||||
(name)[_bit_byte(bit)] |= _bit_mask(bit)
|
|
||||||
|
|
||||||
/* clear bit N of bitstring name */
|
|
||||||
#define bit_clear(name, bit) \
|
|
||||||
(name)[_bit_byte(bit)] &= ~_bit_mask(bit)
|
|
||||||
|
|
||||||
/* clear bits start ... stop in bitstring */
|
|
||||||
#define bit_nclear(name, start, stop) { \
|
|
||||||
register bitstr_t *_name = name; \
|
|
||||||
register int _start = start, _stop = stop; \
|
|
||||||
register int _startbyte = _bit_byte(_start); \
|
|
||||||
register int _stopbyte = _bit_byte(_stop); \
|
|
||||||
if (_startbyte == _stopbyte) { \
|
|
||||||
_name[_startbyte] &= ((0xff >> (8 - (_start&0x7))) | \
|
|
||||||
(0xff << ((_stop&0x7) + 1))); \
|
|
||||||
} else { \
|
|
||||||
_name[_startbyte] &= 0xff >> (8 - (_start&0x7)); \
|
|
||||||
while (++_startbyte < _stopbyte) \
|
|
||||||
_name[_startbyte] = 0; \
|
|
||||||
_name[_stopbyte] &= 0xff << ((_stop&0x7) + 1); \
|
|
||||||
} \
|
|
||||||
}
|
|
||||||
|
|
||||||
/* set bits start ... stop in bitstring */
|
|
||||||
#define bit_nset(name, start, stop) { \
|
|
||||||
register bitstr_t *_name = name; \
|
|
||||||
register int _start = start, _stop = stop; \
|
|
||||||
register int _startbyte = _bit_byte(_start); \
|
|
||||||
register int _stopbyte = _bit_byte(_stop); \
|
|
||||||
if (_startbyte == _stopbyte) { \
|
|
||||||
_name[_startbyte] |= ((0xff << (_start&0x7)) & \
|
|
||||||
(0xff >> (7 - (_stop&0x7)))); \
|
|
||||||
} else { \
|
|
||||||
_name[_startbyte] |= 0xff << ((_start)&0x7); \
|
|
||||||
while (++_startbyte < _stopbyte) \
|
|
||||||
_name[_startbyte] = 0xff; \
|
|
||||||
_name[_stopbyte] |= 0xff >> (7 - (_stop&0x7)); \
|
|
||||||
} \
|
|
||||||
}
|
|
||||||
|
|
||||||
/* find first bit clear in name */
|
|
||||||
#define bit_ffc(name, nbits, value) { \
|
|
||||||
register bitstr_t *_name = name; \
|
|
||||||
register int _byte, _nbits = nbits; \
|
|
||||||
register int _stopbyte = _bit_byte(_nbits), _value = -1; \
|
|
||||||
for (_byte = 0; _byte <= _stopbyte; ++_byte) \
|
|
||||||
if (_name[_byte] != 0xff) { \
|
|
||||||
_value = _byte << 3; \
|
|
||||||
for (_stopbyte = _name[_byte]; (_stopbyte&0x1); \
|
|
||||||
++_value, _stopbyte >>= 1); \
|
|
||||||
break; \
|
|
||||||
} \
|
|
||||||
*(value) = _value; \
|
|
||||||
}
|
|
||||||
|
|
||||||
/* find first bit set in name */
|
|
||||||
#define bit_ffs(name, nbits, value) { \
|
|
||||||
register bitstr_t *_name = name; \
|
|
||||||
register int _byte, _nbits = nbits; \
|
|
||||||
register int _stopbyte = _bit_byte(_nbits), _value = -1; \
|
|
||||||
for (_byte = 0; _byte <= _stopbyte; ++_byte) \
|
|
||||||
if (_name[_byte]) { \
|
|
||||||
_value = _byte << 3; \
|
|
||||||
for (_stopbyte = _name[_byte]; !(_stopbyte&0x1); \
|
|
||||||
++_value, _stopbyte >>= 1); \
|
|
||||||
break; \
|
|
||||||
} \
|
|
||||||
*(value) = _value; \
|
|
||||||
}
|
|
||||||
@ -1,23 +0,0 @@
|
|||||||
#!/bin/sh
|
|
||||||
|
|
||||||
# putman.sh - install a man page according to local custom
|
|
||||||
# vixie 27dec93 [original]
|
|
||||||
#
|
|
||||||
# $Id: putman.sh,v 1.1.1.1 1994/01/05 20:40:16 jtc Exp $
|
|
||||||
|
|
||||||
PAGE=$1
|
|
||||||
DIR=$2
|
|
||||||
|
|
||||||
SECT=`expr $PAGE : '[a-z]*.\([0-9]\)'`
|
|
||||||
|
|
||||||
[ -d $DIR/man$SECT ] && {
|
|
||||||
set -x
|
|
||||||
cp $PAGE $DIR/man$SECT/$PAGE
|
|
||||||
set +x
|
|
||||||
} || {
|
|
||||||
set -x
|
|
||||||
nroff -man $PAGE >$DIR/cat$SECT/`basename $PAGE .$SECT`.0
|
|
||||||
set +x
|
|
||||||
}
|
|
||||||
|
|
||||||
exit 0
|
|
||||||
Loading…
Reference in New Issue
Block a user