SVM Mac 157
Rubrique Pratique
Terminal
1 page

Tout système Unix qui se respecte se doit de fournir un mécanisme de déclenchement de tâches répétitives, répétitives, répétitives…
Depuis la nuit des temps et sur la l’ensemble des versions d’Unix, ce rôle échoit à l’outil cron et ses fichiers crontab.
Yannick Cadin

Envoyer un courrier toutes les heures?
% sudo sh -c 'echo "@hourly root echo Finir article sur cron | mail -s Au\ boulot\ feignant yannick@diablotin.com" >> /etc/crontab'
Explication de texte : l’expression complète signifie que l’on adopte l’identité de root (avec sudo) pour lancer un interpréteur de commande (sh) au travers duquel (option -c) nous allons afficher (echo) la ligne @hourly root qui sera en réalité ajoutée (grâce à la redirection >>) à la fin du fichier /etc/crontab. Cette ligne elle-même indique qu’au début de chaque heure (symbolisé par le label réservé @hourly), sous la responsabilité de root, il faudra afficher un texte (« Finir article sur cron ») qui sera redirigé via un tube de communication (|) pour devenir le corps de message de la commande mail, à droite du tube, à laquelle on passe en plus comme paramètres le sujet du courrier (option -s) et enfin le destinataire de la missive (yannick@diablotin.com).
Vous remarquerez tout particulièrement l’emploi des délimiteurs de chaînes de caractères (guillemets et apostrophes) ainsi que l’utilisation de l’antislash qui considère le caractère qui le suit immédiatement comme un littéral et non comme un symbole spécial (ici nous voulons que les espaces restent des espaces plutôt que d’être interprétés comme des séparateurs de paramètres).

Programmer une copie de fichiers importants le vendredi soir après le travail, à l’exception des mois de juillet et août ?
% sudo sh -c 'echo "30 18 * 1-6,9-12 fri root ditto -V -rsrc /Users/carole/Documents /Volumes/DisqueBackup/DocsCarole" >> /etc/crontab'
Dans l’exemple précédent, on se simplifiait le travail en utilisant le label prédéfini @hourly (il en existe une demi-douzaine d’autres). Ici au contraire, on renseigne soi-même l’ensemble des valeurs, pas moins de 5, qui permettent de définir précisément la périodicité de déclenchement de notre action. La première donne la ou les minutes (à la demi ici), la deuxième l’heure ou les heures (18 heures), la troisième les jours du mois (ici n’importe lequel sans restriction), la quatrième les mois (intervalle allant de janvier à juin auquel s’ajoute l’intervalle allant de septembre à décembre), la dernière le ou les jours de la semaine (juste vendredi, abrégé en fri, les premières lettres du mot anglais correspondant, Friday). Le reste parle de lui-même, ditto réalise une copie récursive.
Attention, Finder vous trompe. Le dossier /Utilisateurs par exemple se nomme en réalité /Users. Méfiez-vous et utilisez les vrais noms des dossiers dans vos chemins d’accès.

Où se trouve la magie ?
% pas ax | grep cron
Comment expliquer que la simple modification d’un fichier, /etc/crontab en l’occurrence, donne lieu à l’exécution régulière de tâches ? Le résultat de la commande ci-dessus vous montre qu’un programme nommé cron fonctionne en permanence sur votre machine, et ce depuis son démarrage, moment où il lit /etc/crontab. Il faut ajouter à cette incomplète explication que cron se réveille toutes les minutes, vérifie s’il est temps de lancer une tâche, sans omettre auparavant de tester la date de dernière modification du contenu du fichier /etc/crontab afin de relire ce dernier en cas de changement.

Quel est le contenu initial du fichier /etc/crontab ?
% cat /etc/crontab
Votre Mac OS X est installé avec une TABle de CRON (d’où le nom crontab) préprogrammée car, avec l’étape de démarrage du système, c’est le seul moyen mis à sa disposition pour lui permettre de passer en revue à intervalle régulier un certain nombre de tâches à entreprendre, en particulier pour l’actualisation de différentes bases de données et aussi pour des opérations de nettoyage.
Afin de ne pas encombrer le fichier /etc/crontab, les actions répétitives à accomplir prévues par les concepteurs d’OS X sont reléguées dans trois dossiers, daily, weekly et monthly, tous rangés dans /etc/periodic et dont les noms sont suffisamment explicites. Vous remarquerez tout de même qu’ils sont tous lancés entre 3 heures 15 et 5 heures 30 du MATIN. Et oui, on retrouve là une dimension historique, nous sommes sur un Unix et un tel système est censé tourner 24 heures sur 24, 365 jours par an, et parfois même 366.
L’analyse des scripts contenus dans daily, weekly et monthly est intéressante à plus d’un titre. Non seulement on y voit clairement toutes les actions entreprises en coulisse mais on y découvre aussi des invocations à des scripts optionnels, respectivement /etc/daily.local, /etc/weekly.local et /etc/monthly.local. Le principe là encore est de ne pas tout mélanger, notamment ici pour distinguer les éléments fournis par Apple de vos propres ajouts. En créant un fichier /etc/weekly.local, vous avez l’assurance de voir vos traitements lancés tous les samedis à 4 heures 30 du matin (sous réserve d’ordinateur allumé) sans avoir à altérer les fichiers /etc/crontab ou les scripts présents dans /etc/weekly. Ceci peut éviter quelques désagréments lors des mises à jours d’OS X. Une alternative consiste aussi à placer vos propres scripts dans le ou les dossiers daily, weekly et monthly appropriés.
(AVANT JAGUAR) sont reléguées dans trois  scripts, daily, weekly et monthly, tous rangés dans /etc et dont les noms sont suffisamment explicites. Vous remarquerez tout de même qu’ils sont tous lancés entre 3 heures 15 et 5 heures 30 du MATIN. Et oui, on retrouve là une dimension historique, nous sommes sur un Unix et un tel système est censé tourner 24 heures sur 24, 365 jours par an, et parfois même 366.
Le décryptage ??L’analyse des scripts daily, weekly et monthly est intéressant à plus d’un titre. Non seulement on y voit clairement toutes les actions entreprises en coulisse mais on y découvre aussi des invocations à des scripts optionnels, respectivement /etc/daily.local, /etc/weekly.local et /etc/monthly.local. Le principe là encore est de ne pas tout mélanger, notamment ici pour distinguer les éléments fournis par Apple de vos propres ajouts. En créant un fichier /etc/weekly.local, vous avez l’assurance de voir vos traitements lancés tous les samedis à 4 heures 30 du matin (sous réserve d’ordinateur allumé) sans avoir à altérer les fichiers /etc/crontab ou /etc/weekly. Ceci peut éviter quelques désagréments lors des mises à jours d’OS X.
À noter que les lignes débutant par un dièse sont considérées comme des commentaires (un grand classique dans les conventions Unix).

Modifier  la table ?
% sudo vi /etc/crontab		ou
% sudo pico /etc/crontab		ou encore
% sudo /Applications/TextEdit.app/Contents/MacOS/TextEdit /etc/crontab
Si vous voulez supprimer ou corriger une ligne du fichier, la seule solution est de l’éditer. La première possibilité s’adresse aux utilisateurs Unix chevronnés pour qui vi est un investissement quasi obligatoire. La deuxième possibilité est à l’attention des aspirants utilisateurs Unix chevronnés puisque, bien que plus simple d’abord que vi, on ne quittte pas Terminal. Enfin, la dernière alternative est réservée aux irréductibles d’Aqua puisqu’elle a pour effet d’ouvrir /etc/crontab dans TextEdit (IMPORTANT : pour que le fichier soit lu avec les privilèges de root, il faut que TextEdit ne soit pas lancé au moment où l’on exécute la commande proposée ici).

En savoir plus ?
% man 5 crontab
Le détail de la syntaxe autorisée pour constituer le fichier /etc/crontab peut être obtenu depuis Terminal avec la commande ci-dessus qui permet de voir la documentation relative à crontab dans la section 5 du manuel électronique. La section 5 s’intéresse aux formats de fichiers. Dans le cas présent, en l’absence du numéro de section, vous obtiendriez les explications concernant le programme crontab (en section 1) et non celles concernant le fichier de même nom. Ceci ne marche, bien évidemment, que si les pages man ont été installées en totalité, ce qui n’est pas le cas, et c’est très malheureux, sur les versions de Mac OS X pré-installées.