Re: gérer des fichiers log

In article <si9urh$mad$1@shakotay.alphanet.ch>,
 Marc SCHAEFER <schaefer@alphanet.ch> wrote:

Ca fait 25 ans que je n'ai plus écrit d'Ada.

8-o
???

tu as déjà programmé en Ada, et maintenant tu développes de l'embarqué
en C ?

???

est-ce que tu as eu une super mauvaise expérience en Ada il y a 25 ans,
ou est-ce qu'on t'impose à toutes forces ton environnement de
développement ?


il y a 25 ans, Ada95 venait de sortir, donc si tu n'a fait que du Ada83,
il y en a eu des améliorations depuis ! ;-)
POO, contrats, ...

voilà une excellente présentation :-)
https://www.youtube.com/watch?v=b5lRyBRk0d8
(j'adore le "langage épais" :-) )

bon, a priori, je n'ai pas besoin de pousser la résilience de mon
logiciel au point où on puisse le changer de place pendant son
exécution,

 
C'était pour te faire comprendre la philosophie complètement différente
de UNIX concernant les chemins.

je sais que c'est un peu spécial :-)
je pense que si c'est moi qui l'avais fait, je l'aurais fait un peu
différemment, genre plus intuitif ;-)

Il n'est en général pas une bonne
pratique de `deviner' où est "son" répertoire.  Soit c'est en dur
(/etc/application/), ~/.application, etc), soit c'est une variable
d'environnement, soit c'est configuré quelque part.

en fait, c'était déjà programmé dedans quand je l'ai repris, pour
permettre au logiciel de trouver ses images, et je ne pensais pas que ça
poserais des pbs de le réutiliser pour faire les fichiers de logs :-)

alors je pense qu'à très court terme je vais faire comme ça quand même,
parce que :
- pour l'instant on ne peut pas l'installer, on ne peut le faire marcher
que dans le répertoire des sources,
- j'aimerais mieux, tant que je n'ai pas évolué, que tout ce qui
concerne ce logiciel reste à l'intérieur de son répertoire,
- je ne sens pas la prise en charge d'un wrapper script pour tout le
monde.

mais je garde bien en tête toutes tes recommandations, et je vais tacher
au moins de le rendre configurable à moyen terme :-)

en fait, ce que j'essaye de faire maintenant, c'est bien comprendre le
pb ainsi que toutes les solutions,
pour pouvoir bien concevoir les modules que je suis en train de revoir
maintenant,
de manière à ne pas devoir les revoir de fond en comble le jour où je
revois d'autres modules pour m'approcher un peu plus de l'idéal
(par exemple si j'ajoute la prise en charge d'un fichier de config dans
6 mois)

 
Et changer le répertoire courant durant l'exécution, c'est changer
la référence et donc on a des soucis pour tous les arguments de ligne de
commande

même si a priori on peut aussi juste lire les fichiers immédiatement à
l'ouverture (typiquement, pour un fichier de config qu'on ne modifie
pas, on peut faire ça),
je ne vois pas l'intérêt de changer le répertoire courant, donc même si
c'était comme ça quand je l'ai repris je vais le virer vite fait ;-)

 

le Filesystem Hierarchy Standard (même s'il devient apparemment
obsolète).

 
qu'est ce que c'est ?
(il a peut être besoin d'une mise à jour ?)

 
https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard

effectivement, c'est bien précisé là :
https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s08.html
chaque application -> directement dans le "user's home directory"

dans la note 7, ça parle de trucs que je ne connais pas, et pas un mot
sur $HOME, même pas en mal !
est ce que $HOME est suffisamment fiable et portable quand même ?


j'allais dire qu'ils devraient proposer des regroupements du genre
~/.config/ , mais en fait ils proposent la "XDG Base Directory
Specification"
<https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.
html>

donc même si c'est pas absolument mon idéal, cette Spécification existe,
allons-y !
amtha, ça serais bien que le Filesystem Hierarchy Standard insiste un
peu plus, pour que tout le monde utilise la XDG Base Directory
Specification :-)


connais tu ça ? (c'est là d'où vient le ~/.config/ apparemment)

à ton avis, est ce qu'il y a des prerequis pour utiliser cette
Spécification ?

si on décide de s'y mettre,
- est ce qu'on peut juste prendre les petits morceaux qui nous plaisent ?
(par exemple, regarder $XDG_DATA_HOME mais pas $XDG_DATA_DIRS ni
$datadir, ou mettre une autre valeur par défaut que celle indiquée)
- ou alors est ce qu'on doit la prendre en charge entièrement et
rigoureusement, sous peine de fiche un gros bazar ?

mais au fait, peut être considères-tu que les applications ne devraient
juste pas essayer de s'en mêler, et que c'est aux intégrateurs de faire
l'interface via le wrapper script ?

 
Apparemment c'est surtout que certaines distributions ont laissé tombé.

ah dommage
(sais tu si elles avaient de bonnes raisons de le faire ?)

 

et là le rangement en sous-répertoires retrouve tout son intérêt pour
la commodité.

 
C'est juste.

et la XDG Base Directory Specification y remédie :-)

reste les developpeurs à convaincre, surtout ceux qui utilisent snap ;-)

 

en fait, je pense que j'aurai l'occasion de faire une fenêtre de
"préférences", qui va éditer "en mode graphique" un fichier de ce genre
(donc ce fichier sera écrit et lu symétriquement, et pas édité à la
main).

 
Dommage, j'adore quand je peux générer ce genre de fichier
automatiquement, par exemple pour préconfigurer une salle de machines
ou tester des applications automatiquement.
 
Donc: configuration stocké en format texte, dans
~/.config/application/config par exemple.
 
Quel format texte?  Totalement égal si je peux le générer avec un
template.

ok,
connais-tu un endroit (tutoriel ?) qui explique comment fonctionnent les
templates ?

 

j'ai cru comprendre que pour permettre aux utilisateurs de Windows de
double cliquer sur un fichier pour l'ouvrir, il est nécessaire de

 
Microsoft est pour moi hors sujet.

pour moi c'est pas hors sujet,
parce que je sais qu'il y a des gens qui s'en sont servis,
puisqu'il y a dans le code et dans le log SVN des notes concernant des
corrections de bug pour que ça puisse mieux fonctionner sous Windows :-)

donc je considère ça comme un prerequis du mainteneur qui me l'a confié
;-)
même s'il ne me l'a pas dit comme ça, je considère que ça fait partie de
ma mission de ne pas casser ce qui marche ;-)

 

prendre en charge l'indication du fichier cliqué comme argument unique
(je ne sais pas comment ça se passe sur les autres plateformes)

 
La plupart du temps le GUI va simplement lancer /usr/bin/toto
nom-fichier-double-cliqué.

Toutefois, la plupart des GUI permettent de
configurer le comportement avec des templates (exemple: programme %f
dans l'association MIME), il me semble.

ok donc ça c'est le boulot de l'intégrateur.
tant que je ne suis pas au point là dessus, je souhaite que ça puisse
fonctionner sans intégration.

 

donc, comment faire qqch qui réponde à ton besoin et qui soit compatible
avec ce comportement de Windows ?

Dans mon optique, le monde Microsoft ne m'intéresse pas, donc je ne
vais pas trop élaborer.

pour la question précédente, en fait on dirait que Windows et les autres
plateformes sont similaires.

il faut juste trouver un mécanisme qui soit compatible avec ça sans
wrapper script.
donc pas de fichier de config obligatoire, mais tu as dit que ça pouvait
être facultatif.

il faudrait aussi que ça soit compatible avec la manière d'utiliser le
logiciel ...
mais non en fait, puisque je peux séparer la partie gui et la partie cli
...
sauf que la partie cli aussi risque d'avoir besoin du fichier de config
...

(une suggestion ?)

dans quels cas on peut vouloir exprimer un chemin relativement depuis un
autre répertoire ?

 
C'était lié à ton file-browser qui change de répertoire courant.

tu disais "sémantiquement, tu vas changer de répertoire à chaque fois
que tu veux relativement exprimer un chemin depuis ce répertoire"

ah oui, tu disais ça en lien avec le file-browser ?
je croyais que c'était une généralité et qu'il y avait des cas où
c'était vraiment utile.

mais avec le file-browser ... comme toi, je ne vois pas l'intérêt de
faire des bugs ailleurs ...

Je constate aussi qu'il y a un problème inhérent aux GUI ou plutôt aux
applications qui n'acceptent pas d'être lancées deux fois.

Pour moi, c'est un bug, mais c'est à quoi s'attendent les utilisateurs
Microsoft et Apple.

je suis un futur-ex Apple ;-)

mais il y a un truc qu'il faut que j'essaye de faire ;-)
ne pas essayer d'être parfait des le début !!! :-D

je me demande ce qu'il peut y avoir comme pb quand par exemple 2
instances veulent modifier le même fichier ...
mais tant pis, cette affaire là je ne m'en occupe pas,
je laisse ça aux OS, aux intégrateurs, aux utilisateurs ...

 
Comme quoi faire du GUI *et* de la ligne de commande c'est compliqué.

veux tu dire que tu recommandes de tjr lancer les applications GUI
depuis un bureau GUI et pas depuis un terminal ?

- parce que je ne sens pas la prise en charge d'un wrapper script qui va
marcher à tous les coups sur toutes les plateformes
(voir l'autre branche du fil)

 
Un script pour chaque plateforme, plutôt.

oui, donc voilà : il faut que ça puisse marcher sans.

 

si je te comprend bien, écrire sur stdout et stderr ne provoque jamais
aucune erreur d'aucune sorte ? le pire qui puisse arriver, c'est que ce
qu'on y envoie tombe dans un puits sans fond ?

 
Du point de vue de ton application, il est possible que l'écriture dans
ces fichiers retourne une erreur, oui.

ah bon ?
concrètement, dans quels cas ça peut arriver ?

A toi de la traiter (p.ex. en
l'ignorant ou en la reportant au niveau supérieur: exemple: erreur
d'écriture dans stdout -> warning unique dans stderr).
 

ce dont je parlais était d'ignorer les erreurs d'écriture dans les
fichiers de logs, puisque les sorties standards suffisent pour récupérer
l'information.

 
Erreur d'écriture dans fichier de log -> erreur dans stderr et dialogue
graphique vu que c'est quand même quelque chose de rare.

une erreur d'écriture dans un fichier de log, surtout si on inclus
l'ouverture en écriture, qui fait une erreur en cas d'interdiction,
ça peut arriver si par exemple on installe mon logiciel mal fichu comme
il est à un niveau système.


mais surtout :
d'après le reste du fil, j'ai cru comprendre que tu préférais plutôt que
mon logiciel ne fasse pas de fichiers de log.

alors j'ai eu tendance à considérer ça comme facultatif, cad :
moi j'en veux, alors je les fait quand même,
mais si pour une raison quelconque il y a un pb pour les faire, comme ça
n'est pas un pb pour toi, j'ai juste à l'ignorer.

donc par exemple : s'il y a un pb à la lecture du fichier de config, je
ne connais pas encore l'emplacement des fichiers de log,
mais c'est pas grave, puisque c'est facultatif on ne les fait pas, c'est
simple.


mais peut être que, tout en préférant les logiciels qui ne s'en mêlent
pas,
tu considères que si on dit dans le fichier de config qu'on veut des
fichiers de log, alors ils doivent être vraiment faits ?

et donc, doivent-ils aussi être complets ?
s'il y a un pb à la lecture du fichier de config (ou avant),
on ne sait même pas encore à ce moment là si on veut des fichiers de log
ou pas :
que fait-on avec les erreurs ou autres messages qui ont lieu à ce moment
là ?


que me suggères tu à cette étape ? :-)

--
RAPID maintainer
http://savannah.nongnu.org/projects/rapid/