crontab

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 superuser 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 envi-
       ronment 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 resyn-
       chronize and not issue missed commands.  No  attempt  will
       be  made  to issue commands lost due to a reboot, and com-
       mands 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 vix-
       iecron, 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 specified 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 practice is to run  your  command  with
       exec  to  keep  the process table uncluttered.  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 overhead 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.west.oic.com)