crontab

Edit the crontab file for the current user

$ crontab -e

$ sudo crontab -e -u [user]

$ crontab [path/to/file]

$ crontab -l

$ crontab -r

$ 0 10 * * * [command_to_execute]

$ */10 * * * * [command_to_execute]

$ 30 2 * * Fri /[path/to/script.sh]

crontab [-u user] file
crontab [-u user] [-e | -l | -r | -i]

-e
    Edit the current crontab file. If no crontab exists for the user, one is created.

-l
    List the contents of the current crontab file to standard output.

-r
    Remove the current crontab file, deleting all scheduled jobs for the user.

-i
    Prompt for confirmation before removing the crontab file (used in conjunction with -r).

-u user
    Specify the user whose crontab is to be manipulated. This option is typically restricted to the superuser (root).

file
    Install the specified file as the new crontab for the current user. The previous crontab is replaced.

crontab manages a user's cron table, a file that contains instructions for the cron daemon. The cron daemon is a time-based job scheduler in Unix-like operating systems. By editing your personal crontab file, you can specify commands or scripts to be executed automatically at predefined intervals.
This automation is crucial for system administration, data backups, log rotation, and running custom applications at specific times without manual intervention. Each entry in a crontab file consists of five time-and-date fields followed by a command. These fields specify the minute, hour, day of the month, month, and day of the week, allowing for precise control over when a task runs. The crontab command provides an interface to edit, list, and remove these scheduled jobs, ensuring a streamlined process for managing automated tasks specific to your user account. It's distinct from the system-wide cron jobs typically configured in /etc/crontab or /etc/cron.d/.

Environment Variables: crontab jobs execute with a minimal set of environment variables. It's often necessary to explicitly set PATH, SHELL, or other required variables within the crontab file or the executed script.
Output Handling: Any output from a cron job (stdout or stderr) is typically mailed to the crontab owner by default. For noisy scripts, this can flood mailboxes; consider redirecting output to /dev/null or log files.
Day of Month vs. Day of Week: A common pitfall is specifying both the 'Day of Month' and 'Day of Week' fields. If both are restricted (not *), the command will execute if either the day of month OR the day of week matches. For example, 0 0 1 * 1 means 'at midnight on the 1st of every month AND every Monday'.

Each line in a crontab file (excluding comments and environment settings) defines a single job and consists of six fields:
minute hour day_of_month month day_of_week command_to_execute
The first five fields specify the time and date, accepting numbers, lists (e.g., 1,3,5), ranges (e.g., 9-17), and step values (e.g., */5 for every 5 minutes). Wildcards (*) represent 'every' value.
Additionally, several special strings can replace the first five time fields for convenience:
@reboot: Run once after system reboot.
@yearly (or @annually): Run once a year.
@monthly: Run once a month.
@weekly: Run once a week.
@daily (or @midnight): Run once a day.
@hourly: Run once an hour.

The ability to use crontab can be controlled by system-wide configuration files, typically /etc/cron.allow and /etc/cron.deny. If cron.allow exists, only users listed within it may use crontab. If cron.allow does not exist but cron.deny does, users listed in cron.deny are prevented from using crontab. If neither file exists, generally all users can use crontab (though specific distributions may vary).

The concept of scheduled tasks, or 'cron' jobs, has been fundamental to Unix-like operating systems since their inception. The cron utility itself was developed at Bell Labs, allowing tasks to be executed periodically. The crontab command emerged as a user-friendly interface to manage personal cron tables. This allowed individual users to define their own scheduled jobs without needing root privileges to modify system-wide cron configurations. Over the years, various cron implementations have evolved, with Vixie cron (now ISC Cron) being a widely adopted standard that influenced much of the crontab functionality seen in modern Linux distributions.

cron(8), crontab(5), at(1), anacron(8)