calendar : gestion des activités du jour

Palaiseau, le dimanche 21 mars 2021

Cher Journal,

ma trouvaille du jour est calendar(1). Il s'agit d'un petit utilitaire de rappel quotidien des activités du jour. L'implémentation présente dans Debian provient essentiellement du système d'exploitation BSD, bien que la première apparition d'une commande calendar remonterait à AT&T UNIX System 7, du moins si j'en croie la section HISTORY du manuel. Ce programme est disponible dans Debian, dans le paquet éponyme calendar :

$ sudo apt install calendar

Le paquet peut me fournir un certain nombre de calendriers par défaut, disponibles dans /usr/share/calendar, ce qui est pratique pour ne pas oublier les jours fériés ou les saints du jour. Par exemple, les jours fériés français sont disponibles dans le sous-répertoire fr_FR/calendar.jferies. Sinon, je peux enregistrer mes propres rappels dans ~/.calendar/calendar. Je peux aussi enregistrer des rappels spécifiques au contexte d'un répertoire dans un fichier local ./calendar ; un appel à la commande calendar n'affichera alors que les rappels présents dans le fichier ./calendar, et rien de ~/.calendar/calendar. Dans un but de d'efficacité, ce que je fais, histoire de ne pas trop me mélanger les pinceaux, c'est de construire mon fichier principal calendar par défaut, puis d'en faire un lien symbolique que je peux atteindre rapidement depuis la racine de mon répertoire home :

$ mkdir ~/.calendar
$ touch ~/.calendar/calendar
$ ln -s ~/.calendar/calendar ~/calendar

Le format du fichier calendar est assez particulier : c'est une combinaison de tables comprenant une date, le caractère tabulation, et une description. Plusieurs fichiers calendar peuvent être combinés ensemble avec le préprocesseur de macros du langage C : cpp. Il y a quelques gros pièges, pour la plupart documentés dans le manuel, comme par exemple, le fait que la date soit en format américain MM/JJ en cas d'indétermination entre le jour et le mois, ce qui est source de confusion pour les peuplades du vieux continent, habituées à la notation JJ/MM(/AAAA). Personnellement, j'aurais beaucoup aimé un meilleur support du format AAAA-MM-JJ, ou ISO 8601, également documenté dans la RFC 3339. J'aurais également aimé la possibilité de faire des rappels uniques pour une année donnée qu'aurait pu introduire ce format, et accessoirement j'ai toujours été fan de pouvoir faire le tri des dates en même temps que le tri alphabétique. Histoire d'avoir un point de départ, voici un exemple de ce que pourrait être mon fichier calendar stockant mes rappels :

/* pour les caractères spéciaux, option spécifique à Debian */
LANG=UTF-8
/* quelque calendriers par défaut, bien pratiques */
#include <calendar.computer>
#include <fr_FR/calendar.jferies>
/* rappels ponctuels */
03-21	penser à tester calendar(1)
/* rappels hebdomadaires */
Sunday	sauvegarde sur disque 1
/* rappels mensuels */
 *-01	sauvegarde sur disque 2
/* rappels annuels */
12-25	anniversaire Jésus
03-14	exercice de restauration de sauvegardes

Le manuel propose même des exemples de rappels pour des spécifications de dates plus poussées, comme le premier mercredi du mois pour la sirène des pompiers, ou quarante jours avant Pâques pour le mercredi des cendres. Pour vérifier que le calendrier se comporte comme attendu, j'ai juste à lancer la commande ci-après, et normalement, une fois que j'ai retrouvé mes petits et rétabli les tabulations à leurs emplacements attendus, je devrais avoir les rappels s'affichant comme suit :

$ calendar
Mar 21*	Printemps
Mar 21 	penser à tester calendar(1)
Mar 21*	sauvegarde sur disque 1

En option, le système peut envoyer des courriels dans la boîte de réception des utilisateurs, à savoir /var/mail/${USER}. Comme je me sers déjà de cette boîte de réception pour mes courriels réguliers, via des outils comme fetchmail ou getmail, je suis à peu près sûr de recevoir mes rappels chaque jour, même si je ne pense pas forcément à lancer la commande calendar pour consulter l'ordre du jour. Par contre, le mécano d'envoi de courriels n'est pas actif par défaut. Il y a deux composants à configurer :

1. le MTA du système doit au moins être autorisé à transmettre des courriels aux utilisateurs locaux ; personnellement, je laisse la configuration pour les connexions vers l'extérieur aux professionnels du courrier électronique. Avec le MTA par défaut de Debian, qui est Exim 4, le plus rapide est de lancer :

   $ sudo dpkg-reconfigure exim4-config

   et puis de sélectionner l'envoi local seul : local delivery only; not on a network ;
2. la variable RUN_DAILY dans le fichier de configuration /etc/default/calendar doit être explicitement passée à true ; ça permet au script cron.daily/calendar de se déclencher entièrement pour envoyer les éventuels courriels de rappels aux différents comptes de la machine :

   # Uncomment the following line if you'd like all of your users'
   # ~/calendar files to be checked daily.  Calendar will send them mail
   # to remind them of upcoming events.  See calendar(1) for more details.
   RUN_DAILY=true

Ceci fait, je peux vérifier que l'envoi de courriels fonctionne ponctuellement, en lançant la commande :

$ sudo calendar -a

En consultant ma boîte de réception système avec mutt, je peux alors voir arriver un courrier intitulé « Sunday's calendar » :

q:Quit  d:Del  u:Undel  s:Save  m:Mail  r:Reply  g:Group  ?:Help       
N To emollier@fusion   2021-03-21 06:25:34 +0100 0.3K Sunday's Calendar








---Mutt: /var/mail/emollier [Msgs:15 New:1 Post:2 204K]---(threads/date
You are on the last message.

Le corps de ce courrier comprends alors les informations suivantes, issues de la combinaison de mon calendrier, et de l'inclusion du calendrier des jours fériés français :

i:Exit  -:PrevPg  <Space>:NextPg v:View Attachm.  d:Del  r:Reply  <Righ
Date: Sun, 21 Mar 2021 06:25:34 +0100                                  
From: Reminder Service <emollier@fusion>                               
To: emollier@fusion                                                    
Subject: Sunday's Calendar                                             

Mar 21* Printemps
Mar 21 	penser à tester calendar(1)
Mar 21*	sauvegarde sur disque 1

-  F- 12/15: Reminder Service       Sunday's Calendar          -- (all)
Top of message is shown.

À l'inverse, si en tant que simple utilisateur, je suis ennuyé de recevoir ces rappels, mais que le personnel en charge de l'administration de la machine les a activé, alors je peux créer un fichier ~/.calendar/nomail. Sa simple présence suffira à stopper le flux quotidien de courriels :

$ touch ~/.calendar/nomail  # désactive la réception des courriels.

Les points positifs de calendar et son infrastructure sont pour moi les suivants :

• les rappels quotidien avec le calendrier de la journée ne nécessitent pas forcément d'avoir une machine perpétuellement allumée, étant donné l'usage de scripts dans cron.daily ;
• le format est suffisamment simple pour être rapidement éditable avec vi ;
• la bibliothèque de rappels disponible comprend de nombreux jours fériés, les saints du jour, diverses chroniques, ce qui est pratique pour les personnes qui, comme moi, réussissent le tour de force d'essayer de se rendre au travail un jour férié ;
• calendar prend en charge les Pâques orthodoxe, via le mot clé Paskha, et catholique, via le mot clé Easter ;
• l'usage du préprocesseur de macros cpp pourrait laisser imaginer la construction de macros avancées pour définir des rappels pour des évènements plus compliqués à définir, mais ce n'est pas fait pour le moment.

Toutefois, j'ai trouvé un grand nombre de points problématiques, que d'aucun pourrait trouver carrément rédhibitoires :

• les rappels spécifiques à un répertoire écrasent les informations du fichier ~/.calendar/calendar par défaut de l'utilisateur, au lieu de s'y ajouter, à moins de définir un :

  #include "/home/emollier/.calendar/calendar"

  ce qui suit la logique du préprocesseur C, mais pourrait être perçu comme un peu dommage ;
• les rappels ne sont pas envoyés quand la machine est éteinte bien évidemment, du coup il ne faut pas hésiter à changer certains réglages pour avoir, par exemple, un rappel de la semaine complète à venir le vendredi, un cas particulier est défini ce jour là à cause de la fin de semaine ;
• la syntaxe pour gérer les calendriers multiples est en partie basée sur le préprocesseur C, ce qui peut être très dérangeant pour les personnes n'ayant jamais travaillé avec ce langage assez particulier ;
• les dates ne sont pas gérées strictement au format RFC 3339, ce qui est normal étant donné les origines AT&T du programme, mais je trouve cela très dommage, cela permettrait de garantir que les dates sont composées dans un format non ambiguë ;
• la coloration syntaxique dans Vim 8.2 peut prêter à confusion : le format MM-JJ, utilisé afin de s'approcher du format RFC 3339, est colorié comme si JJ était un nombre de jour soustrait à MM, ce qui en soit n'a pas forcément beaucoup de sens ;
• l'utilisation obligatoire des tabulations va facilement faire disparaître des rappels consignés, par erreur, avec des espaces entre la date et la description ;
• au surplus, la spécification des dates est centrée sur des conventions anglo-saxonnes, ce qui peut facilement être source de confusion en France, où les gens sont habitués à la notation JJ/MM, d'autant plus que le logiciel va fonctionner comme attendu, aussi longtemps qu'il n'y a pas d'ambiguïté sur les dates : 31/01 est le 31 janvier au lieu de renvoyer une erreur, mais le 01/02 est le deux janvier au lieu du premier février.

À l'évidence, c'est un outil du passé, peu adapté aux manières modernes d'utiliser l'informatique, où désormais chacun accède à ses courriers depuis n'importe où sur terre, utilise la fonctionnalité de calendrier de son MUA, ont des rappels réguliers des rendez-vous qui auront lieu dans le quart d'heure qui va suivre, etc.

J'ai déjà rempli mon fichier calendar avec des rappels pour des expirations de certificats SSL, de renouvellement de clés GPG, d'exercices de restauration de sauvegardes, etc. Maintenant, j'attends de voir quelle erreur va me mettre le nez dedans. Et puis, j'ai toujours un agenda papier pour limiter la casse.

	Name	Last modified	Size
	Parent Directory		-