CRONTAB(1)CRONTAB(1)NAME
crontab - manipulate per-user crontabs (Dillon's Cron)
SYNOPSIS
crontab file [-u user] - replace crontab from file
crontab - [-u user] - replace crontab from stdin
crontab -l [user] - list crontab for user
crontab -e [user] - edit crontab for user
crontab -d [user] - delete crontab for user
crontab -c dir - specify crontab directory
DESCRIPTION
crontab manipulates the crontab for a particular user. Only the supe‐
ruser may specify a different user and/or crontab directory. Generally
the -e option is used to edit your crontab. crontab will use
/usr/bin/vi or the editor specified by your VISUAL environment variable
to edit the crontab.
Unlike other crond/crontabs, this crontab does not try to do everything
under the sun. Frankly, a shell script is much more able to manipulate
the environment then cron and I see no particular reason to use the
user's shell (from his password entry) to run cron commands when this
requires special casing of non-user crontabs, such as those for UUCP.
When a crontab command is run, this crontab runs it with /bin/sh and
sets up only three environment variables: USER, HOME, and SHELL.
crond automatically detects changes in the time. Reverse-indexed time
changes less then an hour old will NOT re-run crontab commands already
issued in the recovered period. Forward-indexed changes less then an
hour into the future will issue missed commands exactly once. Changes
greater then an hour into the past or future cause crond to resynchro‐
nize and not issue missed commands. No attempt will be made to issue
commands lost due to a reboot, and commands are not reissued if the
previously issued command is still running. For example, if you have a
crontab command 'sleep 70' that you wish to run once a minute, cron
will only be able to issue the command once every two minutes. If you
do not like this feature, you can run your commands in the background
with an '&'.
The crontab format is roughly similar to that used by vixiecron, but
without complex features. Individual fields may contain a time, a time
range, a time range with a skip factor, a symbolic range for the day of
week and month in year, and additional subranges delimited with commas.
Blank lines in the crontab or lines that begin with a hash (#) are
ignored. If you specify both a day in the month and a day of week, the
result is effectively ORd... the crontab entry will be run on the spec‐
ified day of week and on the specified day in the month.
# MIN HOUR DAY MONTH DAYOFWEEK COMMAND
# at 6:10 a.m. every day
10 6 * * * date
# every two hours at the top of the hour
0 */2 * * * date
# every two hours from 11p.m. to 7a.m., and at 8a.m.
0 23-7/2,8 * * * date
# at 11:00 a.m. on the 4th and on every mon, tue, wed
0 11 4 * mon-wed date
# 4:00 a.m. on january 1st
0 4 1 jan * date
# once an hour, all output appended to log file
0 4 1 jan * date >>/var/log/messages 2>&1
The command portion of the line is run with /bin/sh -c <command> and
may therefore contain any valid bourne shell command. A common prac‐
tice is to run your command with exec to keep the process table unclut‐
tered. It is also common to redirect output to a log file. If you do
not, and the command generates output on stdout or stderr, the result
will be mailed to the user in question. If you use this mechanism for
special users, such as UUCP, you may want to create an alias for the
user to direct the mail to someone else, such as root or postmaster.
Internally, this cron uses a quick indexing system to reduce CPU over‐
head when looking for commands to execute. Several hundred crontabs
with several thousand entries can be handled without using noticable
CPU resources.
BUGS
Ought to be able to have several crontab files for any given user, as
an organizational tool.
AUTHOR
Matthew Dillon (dillon@apollo.backplane.com)
1 May 1994 CRONTAB(1)