Насколько я понимаю, вы можете написать своих крон, отредактировав
crontab -e
Я нашел несколько источников, которые вместо написания строки задания за строкой ссылаются на сценарий bash в задании cron.
Единственное преимущество, что вы можете объединить множество задач в одно задание cron с помощью сценария bash?
Дополнительный вопрос для новичков: Правка crontab -e правильно относится к одному файлу? Я заметил, что если я открою crontab -e и закрою без редактирования, когда я снова открою файл, появится другое числовое расширение, например:
"/tmp/crontab.XXXXk1DEaM" 0L, 0C
Я, хотя crontab хранится в / var / spool / cron или / etc / crontab ??
Зачем ему хранить cron в папке tmp?
Это зависит от того, что вы делаете с работой.
cron не дает вам реальной среды сценариев, поэтому, если вы делаете что-то более сложное, чем простой вызов пары команд, вы, вероятно, захотите использовать cron для вызова сценария. Вы также можете иметь дело с такими вещами, как расширение переменных в скрипте, что может быть сложно, если вообще возможно, сделать в среде cron.
Временный файл, который вы видите при запуске crontab -e это просто временный файл, который будет очищен после выхода из сеанса редактора. Фактические crontab, которые вы редактируете с помощью этого метода, попадают в / var / spool / cron.
На самом деле, поскольку это относительно простые вопросы, относящиеся к Unix, есть unix.stackexchange.com сторона вещей, которая может быть более полезной.
Итак, для первого вопроса: есть несколько причин использовать bash-скрипт для вашего cronjob:
Как вы упомянули, вы можете объединить множество команд в один сценарий bash. Это намного удобнее, чем просто собрать вместе огромную строку crontab, тем более, что логический поток более очевиден. Сравните:
command1 >/tmp/foo && command2 || command3
vs.
if command1 >/tmp/foo
then
command2
else
command3
fi
Еще одна причина для вызова скрипта в вашем crontab - это то, что вы можете вызывать что-то помимо bash. Например, вы можете вызвать сценарий Perl или даже сценарий php.
Также предположим, что у вас есть какая-то логика, которую вы хотите вызвать вне cron. Затем также имеет смысл поместить эту логику в отдельный сценарий, установленный на вашем сервере. Вы можете запускать этот сценарий по мере необходимости в командной строке, а также можете вызывать его из crontab.
Наконец, обратите внимание, что цитирование в crontabs действительно странно. Канонический пример: crontab съедают знак процента. Если вы поместите «%» в строку crontab, вам фактически придется удвоить его («%%»), иначе cron съест голый знак процента и запутает вас.
По сути, упаковка cronjob в скрипт более безопасна (более стандартные кавычки / экранирование) и более гибкая. Любое задание cron, длина которого превышает одну или две команды, вероятно, следует вынести в отдельный сценарий.
Второй вопрос довольно прост: когда вы редактируете свой crontab, вы не редактируете файл в / var / spool напрямую. Вместо этого crontab -e команда копирует ваш файл crontab во временный файл в / tmp. Часть имени временного файла представляет собой случайную строку, предназначенную для уменьшения вероятности двух вызовов crontab -e от попытки редактировать тот же файл в / tmp.
Временный файл безопаснее редактировать по разным причинам. Во-первых, в случае сбоя процесса редактирования исходный файл остается нетронутым и пригодным для использования. Во-вторых, это позволяет системе проверять новый crontab на наличие синтаксических ошибок перед заменой старого.
Также я буду удивлен, если мне удастся напечатать всю эту запись, ни разу не сказав кукурузную задницу.