Quando si schedulano delle operazioni con cron può risultare utile inserire l’operatore di backtick (`) nella riga di comando passata a cron. L’operatore di backtick in un comando fa si che il comando interno (quello inserito tra i backtick) venga eseguito e il suo output venga inserito al posto del comando racchiuso tra backtick nella riga di comando.
Un uso molto frequente di questo meccanismo è abbinato al comando date, infatti tramite la combinazione backtick + date si possono ottenere nomi di file che contengano la data al proprio interno.
Un problema che si incontra nell’inserire il comando date in un cronjob è che esso ha bisogno del simbolo % per formattare il proprio output. Il carattere % però ha un significato speciale nella scrittura di un cronjob, infatti come si legge nella pagina di manuale di crontab (man 5 crontab):
The ‘‘sixth’’ field (the rest of the line) specifies the command to be run. The entire command portion of the line, up
to a newline or % character, will be executed by /bin/sh or by the shell specified in the SHELL variable of the crontab
file. Percent-signs (%) in the command, unless escaped with backslash (\), will be changed into newline characters,
and all data after the first % will be sent to the command as standard input. There is no way to split a single command
line onto multiple lines, like the shell’s trailing "\".
esso viene interpretato come un newline e tutto ciò che segue tale carattere viene fornito come standard input al comando indicato.
Per evitare questo comportamento è sufficiente fare l’escape dei caratteri % facendoli precedere da un backslash. Ad esempio per creare un backup integrale compresso con gzip di un database mysql ogni notte alle 2 e 45 si può usare il seguente cronjob:
45 2 * * * mysqldump -u backup --databases db_name | gzip > /path/to/backups/db_name.`date +\%F`.sql.gz
Il risultato nella directory di backup dopo alcuni giorni di esecuzione di questo cronjob sarà il seguente:
# ls /path/to/backups db_name.2009-11-01.sql.gz db_name.2009-11-02.sql.gz db_name.2009-11-03.sql.gz db_name.2009-11-04.sql.gz
Va ricordato che per far funzionare senza errori il comando precedente è necessario che l’utente backup (indicato per accedere a mysql con il flag -u) abbia accesso al database db_name senza bisogno di password.
