crontab(1) DG/UX R4.11 crontab(1)
NAME
crontab - install user crontab file
SYNOPSIS
crontab [file]
crontab -e [ username ]
crontab -r [ username ]
crontab -l [ username ]
DESCRIPTION
crontab copies the specified file, or standard input if no file is
specified, into a directory that holds all users' crontabs. The -e
option edits a copy of the current user's crontab file, or creates an
empty file to edit if crontab does not exist. When editing is
complete, the file is installed as the user's crontab file. If a
username is given, the specified user's crontab file is edited,
rather than the current user's crontab file; this may only be done by
a user with the appropriate privilege. The environment variable
EDITOR determines which editor is invoked with the -e option. The
default editor is ed(1). One note of caution, if you plan to remove
all of the entries from a crontab file, use the -r option described
next. The -r option removes a user's crontab from the crontab
directory. crontab -l will list the crontab file for the invoking
user. Only a user with the appropriate privilege can specify a
username following the -r or -l options to remove or list the crontab
file of the specified user.
For systems supporting the DG/UX Capability Option, appropriate
privilege is defined as having one or more specific capabilities
enabled in the effective capability set of the user. See
capdefaults(5) for the default capabilities for this command.
On systems without the DG/UX Capability Option, appropriate privilege
means that your process has an effective UID of root. See the
appropriateprivilege(5) man page for more information.
Users are permitted to use crontab if their names appear in the file
/etc/cron.d/cron.allow. If that file does not exist, the file
/etc/cron.d/cron.deny is checked to determine if the user should be
denied access to crontab. If neither file exists, only root is
allowed to submit a job. If cron.allow does not exist and cron.deny
exists but is empty, global usage is permitted. The allow/deny files
consist of one user name per line.
Security Features
On a system with DG/UX information security, the spool area,
/var/spool/cron/crontabs, is a multilevel directory. All jobs
submitted by crontab will be run at the MAC label of the submitting
process, and with all of the other security attributes being also set
to those of the submitting process. This means that a user may have
several different sets of jobs submitted to cron by crontab, if each
of them is submitted at a different MAC label.
When the -r option is used on a system with DG/UX information
security, the crontab will only be removed at the current process
clearance label. This command must be issued at each clearance level
where a crontab is active.
Crontab Format
A crontab file consists of lines of six fields each. The fields are
separated by spaces or tabs. The first five are integer patterns
that specify the following:
minute (0-59),
hour (0-23),
day of the month (1-31),
month of the year (1-12),
day of the week (0-6 with 0=Sunday).
Each of these patterns may be either an asterisk (meaning all legal
values) or a list of elements separated by commas. An element is
either a number or two numbers separated by a minus sign (meaning an
inclusive range). Note that the specification of days may be made by
two fields (day of the month and day of the week). If both are
specified as a list of elements, both are adhered to. For example, 0
0 1,15 * 1 would run a command on the first and fifteenth of each
month, as well as on every Monday. To specify days by only one
field, the other field should be set to * (for example, 0 0 * * 1
would run a command only on Mondays).
The sixth field of a line in a crontab file is a string that is
executed by the shell at the specified times. A percent character in
this field (unless escaped by \) is translated to a new-line
character. Only the first line (up to a % or end of line) of
the command field is executed by the shell. The other lines are made
available to the command as standard input.
To have cron execute more than one command in a single given crontab
line, separate the comands in the sixth field by semicolons (see
example).
Any line beginning with a # is a comment and will be ignored.
The shell is invoked from your $HOME directory with an arg0 of sh.
Users who desire to have their .profile executed must explicitly do
so in the crontab file. cron supplies a default environment for
every shell, defining HOME, LOGNAME, SHELL (=/bin/sh), and PATH
(=:/bin:/usr/bin:/usr/lbin).
To redirect the standard output of a command to a file foo, append
>foo to the command in the crontab file. To redirect standard error
of a command to a file foo, append 2>foo to the command in the
crontab file (see examples).
If you do not redirect the standard output and standard error of your
commands, any generated output or errors will be mailed to you.
EXAMPLES
The following are examples of valid crontab file lines:
39 15 * * * date "+job1 run at \%H:\%M:\%S"%
Causes the command date "+job1 run at %H:%M:%S" to be executed each
day at 3:39 pm.
30 1 10 6 * echo "abc" 1>/dev/null%
Causes abc to be written to file /dev/null each year on June 10 at
1:30 am.
15 14 * * 0 xyzabc 2>/dev/null%
Executes the command xyzabc every Sunday at 2:15 pm and writes any
errors to the file /dev/null.
0 9 * * * command1 ; command2%
Causes both command1 and command2 to be executed at 9:00 every
morning.
FILES
/etc/cron.d main cron directory
/var/spool/cron/crontabs spool area
/var/cron/log accounting information
/etc/cron.d/cron.allow list of allowed users
/etc/cron.d/cron.deny list of denied users
SEE ALSO
atq(1), atrm(1), sh(1), su(1), ed(1), cron(1M),
appropriateprivilege(5).
capdefaults(5).
NOTES
If you inadvertently enter the crontab command with no argument(s),
do not attempt to get out with a Ctrl-D. This will cause all entries
in your crontab file to be removed. Instead, exit with a DEL.
If a user with the appropriate privilege modifies another user's
crontab file, resulting behavior may be unpredictable. Instead, the
privileged user should first su(1) to the other user's login before
making any changes to the crontab file.
When using crontab with the -e option, if the invoked editor returns
a non-zero status code, crontab will give the user the opportunity to
re-edit the crontab file or abort the edit. One situation where this
might happen would be, when using vi(1), deleting the last lines from
the editor's buffer. This would cause vi to return a non-zero status
when exited.
The string, #ACCOUNTING#, should only be used in the root crontab
file in lines associated with accounting cron jobs. Use of the
string #ACCOUNTING#, with non-accounting cron jobs can lead to
removal of non-accounting cron jobs from the crontab.
Licensed material--property of copyright holder(s)