Je vois comment cette construction fonctionne mais on est ici dans une partie du script qui écrit un chemin dans un fichier de configuration et ça a des implications spécifiques.
Cette dernière version que tu proposes ne respecte pas XDG_DOCUMENTS_DIR si elle existe. Or, je pense qu'il faut la privilégier par rapport au chemin "plan B" hardcodé.
Ensuite, je veux que le fichier journal ne bouge pas d'endroit si XDG_DOCUMENTS_DIR venait à devenir définie sur mon système.
Cependant, je peux imaginer que quelqu'un déplacerait ses dossiers standard et trouver raisonnable que L suive automatiquement (par exemple si la session change de langue, ou que /etc/xdg/user-dirs.defaults est modifié - certains environnements proposent ce renommage automatiquement). C'est un cas qu'on ne peut raisonnablement prendre en charge que si XDG_DOCUMENTS_DIR est définie au moment de la création du fichier de config, sauf à faire de la magie dans le fichier de config et je ne suis pas très fan de ça.
Sans ça, hardcoder le chemin du fichier journal dans le fichier de config serait mieux, le fichier journal n'est pas censé bouger et son emplacement ne devrait pas dépendre de l'existence d'une variable après première configuration idéalement (mais difficile de faire comme ça et permettre le renommage de ces dossiers standard).
Et j'ai utilisé la syntaxe pour se rabattre sur HOME si XDG_DOCUMENTS_DIR venait à ne plus être définie mais en réalité ce n'est pas terrible. Il faudrait certainement éviter cette syntaxe dans le fichier de configuration. Il faudrait plutôt détecter que JOURNAL_FILE n'existe pas / plus et se plaindre. Et en même temps, je veux vraiment éviter de stocker des chemins qui sortent du HOME dans une config autogénérée dans la mesure du possible. Évidemment, si HOME n'est pas défini, all bets are off, mais aussi ça me parait terriblement peu probable.
Voilà l'explication de mes choix. Ce n'est pas parfait parce que c'est le résultat de compromis subtiles.
[^] # Re: L
Posté par raphj (site web personnel) . En réponse au journal Tracim - développement d'une fonctionnalité "journal de bord" - envie de tester ?. Évalué à 2.
Je vois comment cette construction fonctionne mais on est ici dans une partie du script qui écrit un chemin dans un fichier de configuration et ça a des implications spécifiques.
Cette dernière version que tu proposes ne respecte pas XDG_DOCUMENTS_DIR si elle existe. Or, je pense qu'il faut la privilégier par rapport au chemin "plan B" hardcodé.
Ensuite, je veux que le fichier journal ne bouge pas d'endroit si XDG_DOCUMENTS_DIR venait à devenir définie sur mon système.
Cependant, je peux imaginer que quelqu'un déplacerait ses dossiers standard et trouver raisonnable que L suive automatiquement (par exemple si la session change de langue, ou que /etc/xdg/user-dirs.defaults est modifié - certains environnements proposent ce renommage automatiquement). C'est un cas qu'on ne peut raisonnablement prendre en charge que si XDG_DOCUMENTS_DIR est définie au moment de la création du fichier de config, sauf à faire de la magie dans le fichier de config et je ne suis pas très fan de ça.
Sans ça, hardcoder le chemin du fichier journal dans le fichier de config serait mieux, le fichier journal n'est pas censé bouger et son emplacement ne devrait pas dépendre de l'existence d'une variable après première configuration idéalement (mais difficile de faire comme ça et permettre le renommage de ces dossiers standard).
Et j'ai utilisé la syntaxe pour se rabattre sur HOME si XDG_DOCUMENTS_DIR venait à ne plus être définie mais en réalité ce n'est pas terrible. Il faudrait certainement éviter cette syntaxe dans le fichier de configuration. Il faudrait plutôt détecter que JOURNAL_FILE n'existe pas / plus et se plaindre. Et en même temps, je veux vraiment éviter de stocker des chemins qui sortent du HOME dans une config autogénérée dans la mesure du possible. Évidemment, si HOME n'est pas défini, all bets are off, mais aussi ça me parait terriblement peu probable.
Voilà l'explication de mes choix. Ce n'est pas parfait parce que c'est le résultat de compromis subtiles.