![[ICO]](/icons/blank.gif){kind=icon}
![[PARENTDIR]](/icons/back.gif){kind=icon}
Palaiseau, le mercredi 8 juillet 2026.
Cher Journal,
Comme promis dans mon article du 30 juin 2026 au sujet de carnet 1.10.0, j'ai fini par mettre au propre mes notes de test du programme jrnl. J'ai découvert ce projet au détour du bug Debian « Intent To Package » numéro 1139264. Il s'agit d'un logiciel libre qui facilite la tenue d'un journal de bord. Il est diffusé sous licence Gnu GPL version 3 ou plus. À ce titre, il est très proche de ce que j'ai pu implémenter avec mon carnet. Le programme n'est pour l'instant pas disponible dans Debian sid, l'ITP étant toujours ouverte. Toutefois l'application est disponible en tant que module Python dans le Python Package Index et s'installe très bien avec pipx(1) :
$ pipx install jrnl
installed package jrnl 4.3, installed using Python 3.14.6
These apps are now available
- jrnl
done! ✨ 🌟 ✨
Tout comme carnet, jrnl permet de saisir une entrée de journal à la volée depuis la ligne de commande :
$ jrnl ┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓ ┃ Journal 'default' created at /home/emollier/.local/share/jrnl/journal.txt ┃ ┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛ ┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓ ┃ Writing Entry ┃ ┃ To finish writing, press Ctrl+d on a blank line. ┃ ┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛ hello, world
Contrairement à carnet, jrnl ne nécessite pas d'éditeur de texte préalablement configuré ; encore que carnet fait ce qu'il peut pour déterminer des éditeurs par défaut décents et il est toujours possible de configurer ed comme éditeur ligne à ligne, ce qui est utile pour préserver le contexte des résultats de commandes tapées dans le terminal et de leurs sorties. Pour récupérer les entrées du jour :
$ jrnl -on today ┏━━━━━━━━━━━━━━━━━┓ ┃ 1 entry found ┃ ┗━━━━━━━━━━━━━━━━━┛ 2026-06-29 08:17:26 PM hello, world
La saisi de commentaires directement en ligne de commande est également possible, ce que carnet ne sait pas faire aujourd'hui :
$ jrnl bonjour tout le monde. $ jrnl -on today ┏━━━━━━━━━━━━━━━━━━━┓ ┃ 2 entries found ┃ ┗━━━━━━━━━━━━━━━━━━━┛ 2026-06-29 08:17:26 PM hello, world 2026-06-29 08:23:12 PM bonjour tout le monde.
Les entrées peuvent être anti-datées sans efforts :
$ jrnl last week: what did I do? $ jrnl last week: Oh, right, now I remember
Pour sortir toutes les entrées, l'option -on admet la valeur « all » :
$ jrnl -on all ┏━━━━━━━━━━━━━━━━━━━┓ ┃ 4 entries found ┃ ┗━━━━━━━━━━━━━━━━━━━┛ 2026-06-22 09:00:00 AM what did I do? 2026-06-22 09:00:00 AM Oh, right, now I remember 2026-06-29 08:17:26 PM hello, world 2026-06-29 08:23:12 PM bonjour tout le monde.
Il y a quelques subtilités sympathiques, comme la première ligne d'une entrée, qui ne se comporte pas comme les autres :
$ jrnl ┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓ ┃ Writing Entry ┃ ┃ To finish writing, press Ctrl+d on a blank line. ┃ ┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛ Test de jrnl Je suis en train de tester jrnl. La première ligne qui est spécifiée dans l'entrée est spéciale et sera mise en surbrillance lors des retours de commandes. Par ailleurs, c'est la seule ligne affichée lors de certaines situations, comme la sélection d'entrées à effacer d'un journal. $ jrnl -contains test ┏━━━━━━━━━━━━━━━━━┓ ┃ 1 entry found ┃ ┗━━━━━━━━━━━━━━━━━┛ 2026-06-29 08:32:34 PM Test de jrnl Je suis en train de tester jrnl. La première ligne qui est spécifiée dans l'entrée est spéciale et sera mise en surbrillance lors des retours de commandes. Par ailleurs, c'est la seule ligne affichée lors de certaines situations, comme la sélection d'entrées à effacer d'un journal. $ jrnl --delete -on today ┏━━━━━━━━━━━━━━━━━━━┓ ┃ 3 entries found ┃ ┗━━━━━━━━━━━━━━━━━━━┛ Delete entry '2026-06-29 08:17:26 PM hello, world'? [y/N] Delete entry '2026-06-29 08:23:12 PM bonjour tout le monde.'? [y/N] Delete entry '2026-06-29 08:32:34 PM Test de jrnl'? [y/N] ┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓ ┃ No edits to save, because nothing was changed ┃ ┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛
À titre de comparaison, la première ligne dans carnet se trouve être une ligne contextuelle. Elle donne potentiellement une information sur quelque chose qui pouvait se passer au moment de la rédaction du feuillet. Toutefois, elle n'est pas prise en compte lors d'une recherche avec l'option --search. Quelque part, c'est une sorte d'anti-titre, ce qui n'est pas forcément évident de prime abord.
J'ai identifié plusieurs choses qui m'irritent un peu avec jrnl. La plus grosse lacune pour moi, c'est qu'il n'y a rien d'implémenté pour faire de la gestion de tâches. Il est donc nécessaire de bricoler de nouveau avec des motifs de recherche. Je ne pense pas que ce soit une si grosse lacune que ça dans jrnl en pratique pour d'autres personnes que moi. C'est juste que, pour ma façon de prendre des notes, j'ai besoin de ce genre de choses. Il est possible de faire des choses avec des motifs de recherche bien choisis :
$ jrnl -contains '[ ]' ┏━━━━━━━━━━━━━━━━━┓ ┃ 1 entry found ┃ ┗━━━━━━━━━━━━━━━━━┛ 2026-06-29 09:14:21 PM [ ] À l'occasion il faudra que je gère mes tâches.
mais ça fait toujours tout un tas de lettres à taper, qui ne sont pas forcément évidentes en fonction de la façon de définir des tâches. Tandis que dans carnet, la détection de tâches est encodée dans l'option -t, ou --todo :
$ carnet -t […] 48 feuillets found.
J'ai du mal avec les problèmes d'homogénéités entre l'usage des tirets simples « - » et doubles « -- », variable en fonction des commandes de jrnl, mais pas interchangeables. Plus généralement, j'ai un peu de mal avec le nom des options, mais je pense que c'est parce que j'ai passé trop de temps à utiliser mon carnet.
Si l'idée d'avoir un fichier de configuration est bonne, après tout je n'ai toujours rien implémenté de tel dans mon carnet, j'ai plus de mal avec le format de fichier YAML, que je trouve particulièrement compliqué pour faire des choses à peu près simples. Je trouve notamment un peu trop facile de corrompre un fichier YAML par accident en se mélangeant les pinceaux, par exemple entre les espaces et les tabulations, ou s'il faut ou non mettre un tiret.
Je trouve le temps de réaction de la commande pour faire des choses simples un peu irritant. Elle excède presque toujours les 250ms, ce qui est suffisamment long pour être sensible, même si ça reste très rapide en comparaison de certains programmes prenant plusieurs secondes à réagir. J'ai relevé par exemple beaucoup d'overhead pour afficher la version ou bien l'aide :
$ time jrnl --version jrnl v4.3 Copyright © 2012-2023 jrnl contributors This is free software, and you are welcome to redistribute it under certain conditions; for details, see: https://www.gnu.org/licenses/gpl-3.0.html real 0m0.285s user 0m0.244s sys 0m0.033s $ time jrnl --help | wc -l 124 real 0m0.226s user 0m0.170s sys 0m0.057s
En comparaison, carnet est un ordre de grandeur plus rapide pour ces tâches simples :
$ time carnet --version carnet 1.10.0 Copyright (C) 2024-2026, Étienne Mollier <emollier@emlwks999.eu> This program is free software: you can redistribute it and/or modify it under the terms of the GNU Affero General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Affero General Public License for more details. You should have received a copy of the GNU Affero General Public License along with this program. If not, see <https://www.gnu.org/licenses/>. real 0m0.011s user 0m0.008s sys 0m0.003s $ time carnet --help | wc -l 209 real 0m0.012s user 0m0.004s sys 0m0.017s
Un détail amusant, j'ai voulu sortir l'intégralité des entrées de journaux de mon carnet et de mon jrnl de test. Les deux programmes ont pris le même temps. Toutefois, pendant que jrnl a sorti 16 lignes en 197ms :
$ time jrnl -on all | wc -l ┏━━━━━━━━━━━━━━━━━━━┓ ┃ 5 entries found ┃ ┗━━━━━━━━━━━━━━━━━━━┛ 16 real 0m0.197s user 0m0.173s sys 0m0.024s
carnet a sorti 74607 lignes dans le même intervalle de temps :
$ time carnet -s | wc -l 74607 real 0m0.197s user 0m0.255s sys 0m0.059s
Pour référence, le carnet en question comporte plus de huit mille entrées rédigées dans un intervalle de bientôt deux ans :
$ carnet --activity | tail -n-3 Apparent size: 3470.8kiB raw: 3616kiB density: 95.99% Average apparent size per week: 38.6kiB raw: 40.2kiB Number of entries: 8213 of weeks: 90
Les temps passés en mode système et utilisateur sont néanmoins plus longs avec carnet dans les deux cas. Il y eu des fichiers à lire et il n'y a pas de miracles. La raison pour laquelle les temps ne s'additionnent pas dans carnet, c'est que le script shell peut faire usage de la parallèlisation pour les tâches effectuées par des commandes distinctes. Ce n'est pas forcément facilement le cas pour un script écrit en Python.
Du côté de l'ergonomie, je pense que j'ai un problème avec l'encadré qui compte les entrées de journal. Je trouve qu'il détourne trop l'attention du contenu des entrées proprement dites.
J'ai sinon noté quelque fonctionalités que je ne trouve pas utiles, mais peut-être qu'il y a des situations auxquelles je n'ai pas pensé dans lesquelles elles deviennent inestimable. Je pense notamment à la fonctionalité qui permet de chiffrer un journal. Je ne suis pas convaincu que ce genre de fonctionalité soit une bonne idée à implémenter au niveau de l'application, parce qu'implémenter correctement du chiffrement sur disque est compliqué sans fuiter des informations à divers endroits, comme des fichiers temporaires, ou dans de la swap. Selon moi, il est bien plus prudent d'implémenter le chiffrement total du disque avec un outil comme cryptsetup LUKS. Peut-être que c'est utile dans le cadre d'un système de fichier partagé, en plus des disques chiffrés, mais pas à la place des disques chiffrés.
jrnl implémente une fonction de filtrage des recherches dans une fenêtre de temps, avec les options -from et -to, ainsi que -until :
$ jrnl -contains r ┏━━━━━━━━━━━━━━━━━━━┓ ┃ 3 entries found ┃ ┗━━━━━━━━━━━━━━━━━━━┛ 2026-06-22 09:00:00 AM Oh, right, now I remember 2026-06-29 08:17:26 PM hello, world 2026-06-29 08:23:12 PM bonjour tout le monde. $ jrnl -from 2025-01-01 -to 2026-06-28 -contains r ┏━━━━━━━━━━━━━━━━━┓ ┃ 1 entry found ┃ ┗━━━━━━━━━━━━━━━━━┛ 2026-06-22 09:00:00 AM Oh, right, now I remember
Je pense que le manque d'une telle fonctionnalité est une lacune dans carnet et je pense qu'il ne se passera pas longtemps avant que je l'implémente, pour une raison ou pour une autre ; je pense que je peux avoir des gains de temps de recherche en filtrant les recherches à une fenêtre de temps. En revanche, je n'ai pas noté de support pour les expressions rationnelles. Non pas que la fonctionnalité me semble essentielle, mais quand il y en a besoin, elle peut devenir très utile :
$ jrnl -contains remember ┏━━━━━━━━━━━━━━━━━┓ ┃ 1 entry found ┃ ┗━━━━━━━━━━━━━━━━━┛ 2026-06-22 09:00:00 AM Oh, right, now I remember $ jrnl -contains r.\*r ┏━━━━━━━━━━━━━━━━━━━━┓ ┃ no entries found ┃ ┗━━━━━━━━━━━━━━━━━━━━┛
Par ailleurs, j'ai bien aimé le format de fichier utilisé par jrnl. Il est bien plus simple que celui de carnet. J'avais voulu le format de fichier de carnet relativement lisible par un être humain sans nécessiter d'outils particuliers, mais je pense que ça a rendu l'analyse des feuillets compliquée, notamment pour l'implémentation du moteur de recherche intégré. Pour jrnl, le format est un ensemble de timestamps précédés d'un saut de ligne :
$ cat .local/share/jrnl/journal.txt [2026-06-22 09:00:00 AM] what did I do? [2026-06-22 09:00:00 AM] Oh, right, now I remember [2026-06-29 08:17:26 PM] hello, world [2026-06-29 08:23:12 PM] bonjour tout le monde. [2026-06-29 08:32:34 PM] Test de jrnl Je suis en train de tester jrnl. La première ligne qui est spécifiée dans l'entrée est spéciale et sera mise en surbrillance lors des retours de commandes. Par ailleurs, c'est la seule ligne affichée lors de certaines situations, comme la sélection d'entrées à effacer d'un journal. [2026-06-29 09:14:21 PM] [ ] À l'occasion il faudra que je gère mes tâches.
Tout est dans un seul fichier, qui n'est pas édité directement par l'utilisateur de jrnl, contrairement à carnet. jrnl fournit une option --edit pour ouvrir le fichier journal.txt avec un éditeur de texte, mais ce n'est pas la manière normale d'interagir avec le journal. La seule chose qui me chiffonne dans ce format, c'est le marqueur Ante et Post Meridiem, au lieu d'utiliser une horloge de vingt-quatre heures conformément à la RFC 3339 [6]. Ceci dit, les deux formats me semblent suffisamment simples pour permettre des transformations de l'un vers l'autre, en admettant la perte des informations stockées dans les zones indéfinies du format de fichier du carnet, c'est-à-dire partout où il est possible d'insérer du texte qui n'appartient pas à un feuillet, mais qui n'interfère pas avec l'exécution de la commande carnet non plus : la ligne de contexte, l'en-tête de la semaine, mais aussi la possible en-tête de la journée.
Je pense enfin à la capacité à marquer les entrées d'intérêt. Il est possible de marquer ses entrées favorites avec une astérisque « * ». J'avais initialement classé cette option comme étant quelque chose pour lequel je trouvais peu d'intérêt, mais je dois reconnaitre que j'ai deux catégories d'entrées dans mon carnet : des entrées intéressantes d'une part, et de nombreuses entrées de routine d'autre part. Ceci étant, j'aurais tendance à penser que les entrées d'intérêt devraient être davantage reconnaissables de par le fait qu'elles pointent vers des ressources externes, ou bien qu'elles sont la cibles de références depuis d'autres entrées de carnet. C'est pourquoi j'ai eu du mal à me convaincre que cette option est utile. Je pense néanmoins que cette option peut avoir un intérêt pour les très grosses bases de connaissances auxquelles sont adjointes des entrées de journal intersticielles provoquant beaucoup de bruit dans les recherches.
Après avoir testé jrnl, je me suis permis ces quelques critiques. La plupart sont très subjectives et se rapportent à mon ergonomie plus ou moins tordue. De toutes façons, de ce point de vue là, tout le monde est différent. En l'état, sans nécessairement avoir passé en revue tout le code source de jrnl, je ne dissuaderais personne de s'en servir. Au contraire, j'ai même suggéré à un collègue qui a travaillé avec carnet pendant un temps d'utiliser plutôt jrnl, puis de voir ce qui lui convient le mieux. Me concernant, j'ai passé trop de temps avec carnet désormais, et je pense qu'il me sera désormais difficile de m'en passer. Ça me fait également un logiciel à bricoler et je pense que ça me manquerait si j'utilisais les outils préparés par quelqu'un d'autre.
| Name | Last modified | Size |
|---|---|---|---|
| Parent Directory | - |