gérer des fichiers log

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

Thomas <fantome.forums.tDeContes@free.fr.invalid> wrote:
>> > modifier du code source ?
>>
>> Non, pas difficile, si ton application est disponible en code source.
>
> ah bon ? ça m'étonne.
> si c'est vraiment simple ça m'arrangerais bien, ça pourrais changer la
> suite :-)

Bien souvent, les applications UNIX sont données en source, on fait
./configure --avec-les-trucs-qui-nous-arrangent
make all install

chez moi je n'ai que le `make all` pour l'instant.

si j'ai bien compris, le ./configure on le fait comme on veut Í 
l'intérieur, il n'y a que la façon de lui passer les arguments qui doit
plus ou moins respecter un usage.

il y a quand même un truc qui m'échappe :
pourquoi la généralité c'est bcp plus `./configure` que `make config` ?

et on a configuré les chemins qu'on veut.

ok, c'est pas ce Í  quoi je pensais en disant "modifier du code source"
:-)

mais du coup, entretemps, j'ai eu l'idée qui te permettra,
en attendant mieux, de commenter juste une ligne pour arrêter
complètement la génération de fichiers log par le logiciel,
pour te permettre de gérer ça juste avec les sorties standards sans être
dérangé :-)

> http://svn.savannah.gnu.org/viewvc/rapid/branches/gtkada-2.24/src/tki/mcc
> _tki/mcc-msg.ads?revision"4&view=markup ( https://urlpetite.fr/5j2 )
> comment t'y prendrais-tu ?

C'est une déclaration d'interface, je pense ?

oui, en ada on dit une "spécification" :-)

Dans ce cas, je vois deux idées:

- injecter une dépendance Í  un module de configuration générale,

-> variante dynamique

je ne sais pas s'il y a qqch qui existe déjÍ  pour faire ça en ada.

mais c'est pas grave,
ce qui me *** c'est l'analyse de texte, et en fait il y en a déjÍ  pour
lire les fichiers de l'application (qui sont aussi en texte),
donc un peu plus tard, je pourrai reprendre ça pour lire le fichier de
config :-)

- dans le fichier Ada écrire MCC_MSG_ERROR_LOG_FILE_NAME plutÍ´t
que "rapid_errors.log"

-> variante statique

oui, c'est du Preprocessing :-)
je n'en ai jamais fait, mais j'ai vu qu'on peut en faire aussi en ada :-)
d'ailleurs il y a des cas o͹ ça aiderais Í  l'optimisation ! il faudrait
que je regarde ça de plus près !

pour toi, ça ne serais pas trop rigide, de ne plus rien pouvoir
configurer post-compilation ?

> et quand c'est toi qui en as besoin, quel nom donnes tu ?

En général mes fichiers sont gérés en contrÍ´le de version (CVS ou Git),
donc je n'ai pas de fichiers de backup.

tu sauvegardes tes données avec un CVS ?

moi je sauvegarde 1 fois par jour, donc si je travaille 1 journée
entière, j'aime bien avoir des fichiers de backup intermédiaires :-)

et si je te suis bien, dans tous les logiciels que tu fais, même pour
les autres, tu n'as jamais besoin d'en faire non plus ?

Mais certains logiciels que j'utilisent ont une convention .old, .orig,
.bak, ~ ... ça m'est assez égal je dois dire.

si je t'ai bien suivi, tous ces logiciels ajoutent tjr Í  la fin du nom
après leur extension "ordinaire", pour t'empêcher d'ouvrir le fichier de
backup par erreur ?

> moins gênant possible pour toi, si jamais un jour tu devais être
> l'intégrateur de mon logiciel :-)

Bon, le souci c'est que je ne suis même pas sÍ»r de comprendre l'objectif
:)

je ne suis pas sur de comprendre la question.
- comme tu m'a dit avoir le point de vue d'un intégrateur, je pars de
l'hypothèse o͹ tu aurais Í  intégrer le logiciel que je développe.
- je souhaite que, malgré la part de conseils qu'on me donne ici
auxquels je ne souhaite pas me conformer, je réussisse Í  "arrondir les
angles" suffisamment pour que ça ne te rende pas la tache trop
désagréable :-)

j'ai l'impression qu'on en prend le chemin, j'espère que tu la partages
(l'impression) :-)

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

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

Thomas <fantome.forums.tDeContes@free.fr.invalid> wrote:
> le bytecode c'est le truc qu'on fait interpréter par les JVM ?

Le bytecode pur est interprété, pas compilé, par la JVM.

> (dans ce cas lÍ  il y a un peu de compilation quand même, puisque c'est
> du code intermédiaire)

ah bon,
pour moi la compilation c'est transformer le code source en qqch de plus
compact, pas pas forcément du code natif
(mais c'est pas le sujet d'ici)

> par contre, si c'est le logiciel lui-même qui doit envoyer ses logs au
> serveur, je ne crois pas que ça puisse très bien marcher si c'est
> l'intégrateur qui est chargé de gérer les fichiers !

[comme dit Stéphane CARPENTIER : administration système pure]

(dans ce cas lÍ  c'est pas le logiciel lui-même qui gère ça, c'est toi
l'administrateur système qui a parametré ce qu'il fallait autour)

Mais fais attention, tu poses des questions dans toutes les directions,
donc tu risques d'avoir des réponses dans toutes les directions.

je crois que tu veux dire que je m'éparpille, et que tu me suggère de me
recentrer sur ce qui est important pour moi tout de suite.

je t'approuve, et je vais tenter de le faire :-)

ce que je te propose c'est que,
pour un certain nb de choses o͹ je pense avoir compris ce que j'ai ͠
faire,
je vais juste faire des affirmations, sans être certain que j'ai raison,
mais comme ça si c'est le cas tu pourras juste les couper dans tes
réponses suivantes,
ça nous permettra d'avancer plus vite :-)

>> Ah, le debug je l'activerais optionnellement et Í  part.
>
> oui, ça c'est déjÍ  fait (mais si on l'active il faut bien que je le
> traite).
>
> (heu ... ça veut dire quoi "Í  part" ?)

dans un fichier séparé.

ok,
quand j'ai fait les fichiers ça a fait partie de mes réflexes.

mais avec les sorties standards, ça me semble plus compliqué.
(d'o͹ les questions suivantes)

> as tu des exemples d'opérations normales ?
> (on était en mode graphique, lÍ )

L'application graphique a réussi Í  charger le fichier toto.
Le fichier toto a été modifié en appliquant l'instruction blala.

(c'est du debug, donc).

oui :-)
donc ... debug : stdout ou stderr ?
ou peut être que ça dépend si on est en GUI ou en CLI ?

ou alors dis-tu comme Stéphane CARPENTIER : c'est pas forcément très
utile de se casser la tête avec ça ?

> quand tu dis "version du programme",
> est-ce que tu parles seulement d'une option "--version",
> ou bien est-ce que ça vaut aussi pour la version du programme qui est
> affichée automatiquement quand on active le debug ?

LÍ  je ne suis plus, désolé.

désolé, c'est moi qui n'ai pas pris le temps de bien poser les choses :

- je n'ai pas d'option "--version",
est-ce nécessaire ? je ne pense pas, il y a un équivalant dans la GUI.

- je n'ai pas d'option "--help",
est-ce nécessaire ? je ne pense pas, il suffira de taper un truc
incorrect (par ex "--help").

en fait ce que j'ai, c'est du debug optionnel, et quand on l'active ça
affiche la version du programme, sinon non.

vu ce que tu dis sur --help, je suppose que pour --version c'est pareil :
- si j'avais fait une option "--version", ça serais allé sur stdout,
- mais quand on active le debug, ça va avec le debug qq soit le
traitement.

> j'ai oublié de te demander, mais je suppose que si on a un "usage: ..."
> c'est pareil.

Donc, dans ce cas de mettre l'erreur (mauvais arguments) et le message
d'"usage" dans stderr.

Par contre, si tu traites un --help, alors je mettrais la "réponse" dans
stdout.

merci pour la distinction :-)

> si on active le debug, est ce qu'on doit n'avoir aucun msg de debug,
> mais avoir la version qui s'affiche en plus ?

Je ne vois pas pourquoi la version serait nécessaire, ou alors au début
du debug pour t'aider Í  trier les éventuels rapports de bug?

c'était comme ça quand je l'ai repris, alors j'ai supposé que ça faisait
partie des "bonnes pratiques" d'avoir la version qui s'affiche au début
du debug
(de mon coté je n'en sais pas plus)

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

In article <sil1ep$9g5$1@shakotay.alphanet.ch>,
Marc SCHAEFER <schaefer@alphanet.ch> wrote:

Thomas <fantome.forums.tDeContes@free.fr.invalid> wrote:
> tu as déjÍ  programmé en Ada, et maintenant tu développes de l'embarqué
> en C ?

Oui, et je précise: C, pas C++.

Mes langages préférés sont: Perl, C, bash.

ah, je n'aime pas tellement, bash.
je préfère make de bcp, malgré le fait qu'on y retrouve un tas de
défauts du C.

par curiosité, est ce qu'il y a une raison précise, qui fait que tu n'as
pas accroché avec Ada ?? :-)

> 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 ?


> 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 ?

J'ai assez tendance Í  aimer le `convention over configuration', tout en
laissant possible de configurer si on a envie.

j'aime bcp ce principe :-)

j'en déduis que :
- je peux chercher $HOME
- je peux prendre en charge un peu (des morceaux) de XDG Base Directory
Specification, je ne suis pas obligé de faire tout d'un coup.
- je dois tjr prévoir une solution de secours.

>> 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 ?

Exemple en bash:

cat > fichier <<EOF
variable=$ma_variable
EOF

ça ne me parle pas assez, parce qu'il manque des explications autour
pour que je comprenne les différentes "couches".

mais si tu veux on peut voir ça plus tard :
quand je saurai lire un fichier de config, je reviendrai te demander si
ce que je fais te convient, ce qu'il te faut comme template, etc ...

---> SI C'EST DU TEXTE, J'AIME!

compris ;-)

>> 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 ?

Disque plein? Si ce sont des logs ce n'est pas grave. Si ce sont des
données, il faut gérer l'erreur.

Si ce sont des données, on log l'erreur comme d'habitude, aucun pb Í 
l'horizon.

Si ce sont des logs, et si on veut logger l'erreur, il faut faire très
attention Í  ne pas tomber dans une boucle infinie !
surtout que comme le cas est rare, si on ne fait pas attention on a vite
fait de ne pas s'en apercevoir !

mais si ce n'est pas grave, alors j'ai juste Í  ne pas logger l'erreur.

et le seul pb restant Í  l'horizon est de se demander pourquoi il n'y a
pas d'erreur enregistrée dans le fichier alors qu'on l'a demandé.
(mais un Disque plein concerne tous les fichiers, alors ça fera la même
erreur ailleurs, et elle sera Í  nouveau loggée)

> 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.

Oui, si c'est pour que personne ne les lise jamais ...

mon idée c'est pas que les gens les lisent,
mais qu'ils puissent me les envoyer si je leur demande,
sans d'abord avoir Í  trouver comment les faire, et ensuite Í  reproduire
le pb :-)

> donc par exemple : s'il y a un pb Í  la lecture du fichier de config, je

Tu peux écrire sur stderr "pas trouvé la config", ou, si le programme a
été lancé sans arguments de ligne de commande, supposer qu'il a été
lancé en GUI et lÍ  ouvrir un dialogue.

> 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 ?

Comme disait quelqu'un d'autre, on peut aussi imaginer d'activer ou non
le logging et le debugging.

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

les erreurs il faut les communiquer Í  l'utilisateur, soit sous forme
d'un dialogue (GUI) soit sous forme d'une écriture dans stderr.

Les diagnostics de l'applications peuvent aller dans stdout ou dans un
fichier de log, mais peut-être qu'il faudrait les activer explicitement
dans la config.

(diagnostics = debug ?)

(j'ai tendance Í  faire un ET plutÍ´t qu'un OU entre les différentes
interfaces, est-ce un pb ?)

(je ne détaille pas plus, je suppose que ça n'a pas assez d'importance
et que ça ferais juste perdre du temps Í  tout le monde - je peux si tu
le souhaites)


ce que je déduis de tout ce que t'as écrit (juste après les exemples de
templates),
c'est que "ce n'est pas grave" de ne pas écrire de fichiers de log, même
si on a dit dans le fichier de config qu'on en voulait,
donc en cas de pb quelconque avec le fichier, je me contente de stderr
plus éventuellement dialogue GUI.

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

In article <slrnsks8om.83t.sc@scarpet42p.localdomain>,
Stéphane CARPENTIER <sc@fiat-linux.fr> wrote:

Le 24-09-2021, Thomas <fantome.forums.tDeContes@free.fr.invalid> a écrit :
>
> 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 ?

On y arrive.

pardon :
- j'ai pas précisé, je pensais ça en combinaison avec le fichier de
config,
le wrapper script étant présent pour mettre Í  jour le fichier de config
en cas de besoin.
- Marc ne m'a (finalement) pas suggéré de méthode pour passer le fichier
de config sur la ligne de commande Í  mes conditions,
je suppose parce que le chercher Í  des emplacements définis lui
convient,
mais j'ai oublié que dans ce cas, si je veux que la XDG Base Directory
Specification soit prise en charge, il faut que le logiciel gère
lui-même au moins le morceau pour trouver le fichier de config
(après, pour les autres fichiers, ça peut passer uniquement par le
fichier de config)

Soit tu ne veux voire les choses que d'un cÍ´té applicatif. Dans ce cas,
c'est simple, tu balances tout sur stdout et stderr et tu laisses les
intégrateurs, admins systèmes et utilisateurs finaux gérer ce qu'ils en
font comme ils le veulent.

Si les logs sont perdus lancés en mode
graphique, c'est pas grave, l'utilisateur a toujours la possibilité de
lancer en ligne de commande (même le mode graphique) pour voir les logs
qui l'intéressent sur le terminal le jour o͹ il veut comprendre.

mon souci c'est que si qqn a juste des bugs Í  faire remonter, faut pas
que ça soit trop compliqué.

c'est pas comme s'il lui prend simplement l'envie de regarder sous le
capot. dans ce cas lÍ  c'est Í  lui de se remonter les manches.

Soit tu veux absolument, écrire des logs dans un fichier et ça commence
Í  être de l'administration système. Et c'est lÍ  que ça commence Í  être
rigolo.

:-D
(c'est rigolo, alors je rigole :-) )

D'abord, il faut que quoiqu'il arrive, l'absence de possibilité
d'écrire tes logs ne puisse pas empêcher ton appli de tourner. Ça veut
dire que dans ton code tu dois prendre en compte une mauvaise
installation ou un mauvais lancement.

aucun pb, en ada il suffit de rattraper toutes les exceptions.

la seule question qui me tracassait était de savoir dans quelle mesure
ces erreurs lÍ  avaient besoin d'être rapportées Í  leur tour, parce qu'il
y a un risque de tomber dans une boucle infinie.
mais si on n'a pas besoin de les rapporter, aucun pb :-)

Ensuite, il y a le packager qui doit pouvoir choisir le répertoire de
logs par défaut lors de l'installation. Puis, l'admin système doit
pouvoir en choisir un autre pour l'ensemble de ses utilisateurs. Puis,
un utilisateur particulier doit pouvoir choisir o͹ il met les logs pour
lui. Avec la possibilité de changer les logs par une option lors du
démarrage s'il veut faire un test.

C'est pour ça qu'il faut bien que tu fasses attention Í  la préséance
dans le choix des possibilités si c'est défini Í  plusieurs endroits. Il
faut absolument que ce qui est écrit en dur dans ton code ne soit utilisé
que si rien d'autre n'est trouvé. Il faut aussi que l'option en ligne de
commande prenne le dessus sur toutes les variables d'environnement et
fichiers de conf. De même que l'utilisateur final peut écrire dans son
$HOME et pas dans /etc et donc /etc va être réservé Í  l'admin système ou
au packager et être moins prioritaire que $HOME.

tout ça me parait un peu compliqué (pour l'instant),

mais ce qui me parait simple c'est :
- de tout balancer sur stdout et stderr en plus des fichiers,
- qu'on puisse désactiver les fichiers si on les trouve encombrants,
même si je veux qu'ils soient activés par defaut, comme ça on se
retrouve dans le 1er cas.

Pour la séparation de stdout et stderr, c'est pas forcément très utile.
Il me semble préférable de tout mettre au même endroit avec un niveau de
log qui contient un tag et qui est paramétrable. Par exemple, tu mets du
DEBUG, INFO, WARNING et ERROR quand tu envoies tes logs avec un niveau
d'activation faible en temps normal pour avoir moins de lignes et tu
affiches tout quand tu veux comprendre ce qu'il se passe.

j'aime bcp l'idée :-)

je ne sais pas si c'est facile Í  faire très rapidement, parce que :
- il faut que je définisse des règles pour catégoriser les logs
(auj dans mon code les logs ne sont divisés qu'en 2 catégories : DEBUG
et ERROR)
- il faut que je réfléchisse Í  comment j'organise une ligne, pour que ça
soit agréable Í  la fois
- Í  utiliser en traitement automatique (c'était ça ton idée ?),
- quand on l'affiche dans un terminal, en évitant de mettre des
caracteres de contrÍ´le qui vont fiche le bazar ...

est-ce que ça convient, d'avoir tous ces tags qui s'affichent dans le
terminal quand on est en CLI (par ex au moment d'indiquer que les
arguments sont mauvais) ?

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

Thomas <fantome.forums.tDeContes@free.fr.invalid> wrote:

par curiosité, est ce qu'il y a une raison précise, qui fait que tu n'as
pas accroché avec Ada ?? :-)

Les environnements o͹ j'ai fait de l'Ada utilisaient un translateur Ada
vers C, je me suis dis que j'allais plutÍ´t utiliser l'original que la
copie? :)

Non, en fait, aucun des systèmes que j'ai utilisés ou programmés (j'ai
fait de l'écriture allant de drivers bas niveau Í  des OS intermédiaires,
puis du web) n'avaient aucune relation avec l'Ada.

- je dois tjr prévoir une solution de secours.

Ou planter avec un joli message d'erreur.

ce que je fais te convient, ce qu'il te faut comme template, etc ...

Si c'est du texte, c'est l'intégrateur qui fera le template.

c'est que "ce n'est pas grave" de ne pas écrire de fichiers de log, même
si on a dit dans le fichier de config qu'on en voulait,
donc en cas de pb quelconque avec le fichier, je me contente de stderr
plus éventuellement dialogue GUI.

Me semble sensé.

Thomas <fantome.forums.tDeContes@free.fr.invalid> wrote:

pourquoi la généralité c'est bcp plus `./configure` que `make config` ?

configure est tout un environnement Í  son (autoconf), qui génère tout
y.c. Makefile.

oui, c'est du Preprocessing :-)

tout Í  fait.

Tu peux alors centraliser tes définitions dans un fichier de
constantes/préprocessing généré par le configurateur avant compilation.

pour toi, ça ne serais pas trop rigide, de ne plus rien pouvoir
configurer post-compilation ?

Ca dépend de l'application, mais dans certains cas c'est acceptable, en
particulier si c'est open source.

tu sauvegardes tes données avec un CVS ?

Non, je les mets Í  disposition Í  plusieurs endroit de manière
journalisée :)

Et un de ces endroits fait effectivement une sauvegarde automatique hors
site.

et si je te suis bien, dans tous les logiciels que tu fais, même pour
les autres, tu n'as jamais besoin d'en faire non plus ?

Pas sÍ»r de comprendre en quoi avoir un système qui me permet de
retrouver mes données hors site en cas de problème, Í  chaque
modification que je trouve importante est insuffisant?

si je t'ai bien suivi, tous ces logiciels ajoutent tjr Í  la fin du nom
après leur extension "ordinaire", pour t'empêcher d'ouvrir le fichier de
backup par erreur ?

ah non, ils ne m'empêchent de rien du tout?!

D'ailleurs j'aimais bien l'idée du système de fichier Í  versionning de
VMS: le fichier toto devient toto;1 si on le modifie. C'est ainsi que je
vois l'idée que certains programmes ajoutent un ".orig" ou un ~: du
versionning du pauvre.

Le 26-09-2021, Thomas <fantome.forums.tDeContes@free.fr.invalid> a écrit :

In article <slrnsks8om.83t.sc@scarpet42p.localdomain>,
Stéphane CARPENTIER <sc@fiat-linux.fr> wrote:

Soit tu ne veux voire les choses que d'un cÍ´té applicatif. Dans ce cas,
c'est simple, tu balances tout sur stdout et stderr et tu laisses les
intégrateurs, admins systèmes et utilisateurs finaux gérer ce qu'ils en
font comme ils le veulent.

Si les logs sont perdus lancés en mode
graphique, c'est pas grave, l'utilisateur a toujours la possibilité de
lancer en ligne de commande (même le mode graphique) pour voir les logs
qui l'intéressent sur le terminal le jour o͹ il veut comprendre.

mon souci c'est que si qqn a juste des bugs Í  faire remonter, faut pas
que ça soit trop compliqué.

Il n'y a rien de compliqué. Si tu balances tous tes logs sur ta sortie
d'erreur, tu dis Í  l'utilisateur de tapper la commande
« $> monsuperprogramme 2> fichier.log »
et de t'envoyer le fichier « fichier.log » quand il a reproduit le bug.

c'est pas comme s'il lui prend simplement l'envie de regarder sous le
capot. dans ce cas lÍ  c'est Í  lui de se remonter les manches.

Oui, mais pour se remonter les manches, il faut juste que tu lui
permettes de le faire.

D'abord, il faut que quoiqu'il arrive, l'absence de possibilité
d'écrire tes logs ne puisse pas empêcher ton appli de tourner. Ça veut
dire que dans ton code tu dois prendre en compte une mauvaise
installation ou un mauvais lancement.

aucun pb, en ada il suffit de rattraper toutes les exceptions.

la seule question qui me tracassait était de savoir dans quelle mesure
ces erreurs lÍ  avaient besoin d'être rapportées Í  leur tour, parce qu'il
y a un risque de tomber dans une boucle infinie.

Je ne suis pas sÍ»r d'avoir été clair. Imaginons que la seule possibilité
de configuration soit le fichier « /etc/monprog.config » qui est donc Í 
la main de l'intégrateur et de l'admin système. Imaginons toujours que
par erreur, la ligne correspondant Í  l'écriture des logs soit définie Í 
« /bin/monprog.log ». T'as beau catcher toutes tes exceptions, tu les
envoies o͹ tes erreurs ?

mais si on n'a pas besoin de les rapporter, aucun pb :-)

En fait, c'est ton programme, c'est toi qui doit savoir ce qui doit être
rapporté. C'est toi qui dois savoir quels problèmes doivent être traités
ou pas. Si le fichier de conf n'est pas trouvé, est-ce que tu as des
valeurs par défaut qui lui permettent de fonctionner ou pas ? Est-ce que
c'est un problème ou pas ? C'est toi qui dois le savoir.

Le disque est saturé, tu ne peux pas écrire de logs. Soit. Mais est-ce
que la saturation du disque peut poser d'autres problèmes Í  ton
programme ? Pareil, je n'en sais rien, c'est Í  toi de le savoir.

Ensuite, il y a le packager qui doit pouvoir choisir le répertoire de
logs par défaut lors de l'installation. Puis, l'admin système doit
pouvoir en choisir un autre pour l'ensemble de ses utilisateurs. Puis,
un utilisateur particulier doit pouvoir choisir o͹ il met les logs pour
lui. Avec la possibilité de changer les logs par une option lors du
démarrage s'il veut faire un test.

C'est pour ça qu'il faut bien que tu fasses attention Í  la préséance
dans le choix des possibilités si c'est défini Í  plusieurs endroits. Il
faut absolument que ce qui est écrit en dur dans ton code ne soit utilisé
que si rien d'autre n'est trouvé. Il faut aussi que l'option en ligne de
commande prenne le dessus sur toutes les variables d'environnement et
fichiers de conf. De même que l'utilisateur final peut écrire dans son
$HOME et pas dans /etc et donc /etc va être réservé Í  l'admin système ou
au packager et être moins prioritaire que $HOME.

tout ça me parait un peu compliqué (pour l'instant),

Je ne vois pas en quoi c'est plus compliqué que ce que tu écrivais en
cherchant dans les variables systèmes ou les répertoires différents.
Je te dis juste qu'il faut que tu fasses attention Í  l'ordre dans lequel
tu vas chercher tes fichiers.

mais ce qui me parait simple c'est :
- de tout balancer sur stdout et stderr en plus des fichiers,

Ça me semble suttout faire double emploi.

Pour la séparation de stdout et stderr, c'est pas forcément très utile.
Il me semble préférable de tout mettre au même endroit avec un niveau de
log qui contient un tag et qui est paramétrable. Par exemple, tu mets du
DEBUG, INFO, WARNING et ERROR quand tu envoies tes logs avec un niveau
d'activation faible en temps normal pour avoir moins de lignes et tu
affiches tout quand tu veux comprendre ce qu'il se passe.

j'aime bcp l'idée :-)

je ne sais pas si c'est facile Í  faire très rapidement, parce que :
- il faut que je définisse des règles pour catégoriser les logs
(auj dans mon code les logs ne sont divisés qu'en 2 catégories : DEBUG
et ERROR)
- il faut que je réfléchisse Í  comment j'organise une ligne, pour que ça
soit agréable Í  la fois
- Í  utiliser en traitement automatique (c'était ça ton idée ?),
- quand on l'affiche dans un terminal, en évitant de mettre des
caracteres de contrÍ´le qui vont fiche le bazar ...

Mon idée (enfin, c'est pas vraiment la mienne, c'est quand même assez
classique), c'est que tu te programmes une fonction genre
« sendlog(niveau,message) »
Et qu'Í  chaque fois que tu veux envoyer un log, tu passes ton message Í 
cette fonction avec le niveau de logs voulu. Par exemple, en mode debug,
tu vas envoyer toutes les valeurs de tes variables lors d'appels de
fonction dans les logs. Par contre, en mode nominal, ça va surtout te
polluer tes logs et tu n'affiches que les erreurs (éventuellement les
warnings).

Et c'est ta fonction sendlog qui va choisir quoi faire de tes logs :
poubelle si c'est pas le bon niveau de logs et envoi dans le cas
contraire.

Je ne sais pas si tu utilises un framework, ou si tu définis toutes tes
fonctions, mais il doit bien exister quelque chose.

est-ce que ça convient, d'avoir tous ces tags qui s'affichent dans le
terminal quand on est en CLI (par ex au moment d'indiquer que les
arguments sont mauvais) ?

Si c'est une application qui tourne dans un terminal, faut pas que les
logs la rendent inutilisable. Par exemple, la commande find, si tu
cherches toto.txt avec « find / -name toto.txt » en tant que simple
utilisateur, tu vas avoir l'écran rempli d'erreurs des répertoires que
tu n'as pas le droit de lire. et s'il y a une réponse positive, tu ne
vas pas la voir. Alors tu vas plutÍ´t faire ta recherche avec un
« find / -name toto.txt 2> /dev/null ». C'est pareil pour ton
application, il faut qu'elle soit souple.

--
Si vous avez du temps Í  perdre :
https://scarpet42.gitlab.io

In article <siq061$3u2$2@shakotay.alphanet.ch>,
Marc SCHAEFER <schaefer@alphanet.ch> wrote:

Thomas <fantome.forums.tDeContes@free.fr.invalid> wrote:
> pourquoi la généralité c'est bcp plus `./configure` que `make config` ?

configure est tout un environnement Í  son (autoconf), qui génère tout
y.c. Makefile.

je ne comprend pas ...
peux tu reformuler stp ? :-)

> oui, c'est du Preprocessing :-)

tout Í  fait.

Tu peux alors centraliser tes définitions dans un fichier de
constantes/préprocessing généré par le configurateur avant compilation.

oui, pour éviter que le préprocessing soit éparpillé :-)

je ne vais pas le faire immédiatement,
mais il me manquait qqch pour transmettre des données entre le Makefile
et le code ada, on dirait que c'est l'outil qu'il me manquait :-)

et en plus ça permet d'éliminer plein de code mort Í  la compilation :-)

> pour toi, ça ne serais pas trop rigide, de ne plus rien pouvoir
> configurer post-compilation ?

Ca dépend de l'application, mais dans certains cas c'est acceptable, en
particulier si c'est open source.

je verrai ça plus tard.

il y a un coté pratique Í  avoir des constantes Í  la compilation,
mais Í  moyen/long terme, le fichier de config me parait acceptable aussi,
surtout si je veux pouvoir éditer des préférences :-)
(et rien n'empêche d'en avoir 2 : un pour l'intégrateur et un pour la
GUI ;-) )

> et si je te suis bien, dans tous les logiciels que tu fais, même pour
> les autres, tu n'as jamais besoin d'en faire non plus ?

Pas sÍ»r de comprendre en quoi avoir un système qui me permet de
retrouver mes données hors site en cas de problème, Í  chaque
modification que je trouve importante est insuffisant?

tu choisis tes critères,
moi j'aime bien avoir la journalisation comme tu dis ci dessous ;-)

en fait journalisation et sauvegarde n'ont pas exactement le même rÍ´le

moi je n'ai pas de VCS interne, je n'ai que celui qui est publique,
sur lequel je m'efforce de ne publier que des trucs "publiables",
pas des états intermédiaires qui ne marchent pas ;-)

D'ailleurs j'aimais bien l'idée du système de fichier Í  versionning de
VMS: le fichier toto devient toto;1 si on le modifie. C'est ainsi que je
vois l'idée que certains programmes ajoutent un ".orig" ou un ~: du
versionning du pauvre.

d'o͹ l'idée que j'ai proposée en démarrant ce fil, avec les n°
incrémentés dans le nom du fichier ;-)
mais je comprend que ça soit aux utilisateurs de le gérer, et pas aux
applications.

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

In article <slrnsl18t8.29t.sc@scarpet42p.localdomain>,
Stéphane CARPENTIER <sc@fiat-linux.fr> wrote:

Le 26-09-2021, Thomas <fantome.forums.tDeContes@free.fr.invalid> a écrit :
> In article <slrnsks8om.83t.sc@scarpet42p.localdomain>,
> Stéphane CARPENTIER <sc@fiat-linux.fr> wrote:
>
>> Soit tu ne veux voire les choses que d'un cÍ´té applicatif. Dans ce cas,

>> Si les logs sont perdus lancés en mode
>> graphique, c'est pas grave, l'utilisateur a toujours la possibilité de
>> lancer en ligne de commande (même le mode graphique) pour voir les logs
>> qui l'intéressent sur le terminal le jour o͹ il veut comprendre.
>
> mon souci c'est que si qqn a juste des bugs Í  faire remonter, faut pas
> que ça soit trop compliqué.

Il n'y a rien de compliqué. Si tu balances tous tes logs sur ta sortie
d'erreur, tu dis Í  l'utilisateur de tapper la commande
« $> monsuperprogramme 2> fichier.log »
et de t'envoyer le fichier « fichier.log » quand il a reproduit le bug.

et pour Windows,
je vais sur un forum Windows pour demander comment faire, et ensuite je
transmet Í  l'utilisateur la réponse qu'on me donne sans l'avoir
pratiquée.
ou alors je lui répond "vas sur un forum Windows pour demander comment
on fait ça, moi je sais pas".

> c'est pas comme s'il lui prend simplement l'envie de regarder sous le
> capot. dans ce cas lÍ  c'est Í  lui de se remonter les manches.

Oui, mais pour se remonter les manches, il faut juste que tu lui
permettes de le faire.

il me semble que nous n'avons pas de désaccord sur ce point précis.

>> D'abord, il faut que quoiqu'il arrive, l'absence de possibilité
>> d'écrire tes logs ne puisse pas empêcher ton appli de tourner. Ça veut
>> dire que dans ton code tu dois prendre en compte une mauvaise
>> installation ou un mauvais lancement.
>
> aucun pb, en ada il suffit de rattraper toutes les exceptions.
>
> la seule question qui me tracassait était de savoir dans quelle mesure
> ces erreurs lÍ  avaient besoin d'être rapportées Í  leur tour, parce qu'il
> y a un risque de tomber dans une boucle infinie.

Je ne suis pas sÍ»r d'avoir été clair. Imaginons que la seule possibilité
de configuration soit le fichier « /etc/monprog.config » qui est donc Í 
la main de l'intégrateur et de l'admin système. Imaginons toujours que
par erreur, la ligne correspondant Í  l'écriture des logs soit définie Í 
« /bin/monprog.log ». T'as beau catcher toutes tes exceptions, tu les
envoies o͹ tes erreurs ?

sur stderr et dans un dialogue GUI.

> mais si on n'a pas besoin de les rapporter, aucun pb :-)

En fait, c'est ton programme, c'est toi qui doit savoir ce qui doit être
rapporté.

je crois qu'on s'est entendu avec Marc sur le fait qu'il n'y avait pas
de nécessité Í  cet endroit.
et si qqn d'autre me fais changer d'avis plus tard ... tant pis, on
pourra tjr l'améliorer plus tard.

>> Ensuite, il y a le packager qui doit pouvoir choisir le répertoire de
>> logs par défaut lors de l'installation. Puis, l'admin système doit
>> pouvoir en choisir un autre pour l'ensemble de ses utilisateurs. Puis,
>> un utilisateur particulier doit pouvoir choisir o͹ il met les logs pour
>> lui. Avec la possibilité de changer les logs par une option lors du
>> démarrage s'il veut faire un test.
>>
>> C'est pour ça qu'il faut bien que tu fasses attention Í  la préséance
>> dans le choix des possibilités si c'est défini Í  plusieurs endroits. Il
>> faut absolument que ce qui est écrit en dur dans ton code ne soit utilisé
>> que si rien d'autre n'est trouvé. Il faut aussi que l'option en ligne de
>> commande prenne le dessus sur toutes les variables d'environnement et
>> fichiers de conf. De même que l'utilisateur final peut écrire dans son
>> $HOME et pas dans /etc et donc /etc va être réservé Í  l'admin système ou
>> au packager et être moins prioritaire que $HOME.
>
> tout ça me parait un peu compliqué (pour l'instant),

Je ne vois pas en quoi c'est plus compliqué que ce que tu écrivais en
cherchant dans les variables systèmes ou les répertoires différents.
Je te dis juste qu'il faut que tu fasses attention Í  l'ordre dans lequel
tu vas chercher tes fichiers.

oui, en regardant bien, tu as raison :-)

comme c'est fastidieux je reporte,
mais je prend bonne note de ce conseil lÍ , qui me parait de bon sens :-)

> mais ce qui me parait simple c'est :
> - de tout balancer sur stdout et stderr en plus des fichiers,

Ça me semble suttout faire double emploi.

mais ça ne dérange personne.
et ça solutionne le pb que tu as posé ci dessus.

>> Pour la séparation de stdout et stderr, c'est pas forcément très utile.
>> Il me semble préférable de tout mettre au même endroit avec un niveau de
>> log qui contient un tag et qui est paramétrable. Par exemple, tu mets du
>> DEBUG, INFO, WARNING et ERROR quand tu envoies tes logs avec un niveau
>> d'activation faible en temps normal pour avoir moins de lignes et tu
>> affiches tout quand tu veux comprendre ce qu'il se passe.
>
> j'aime bcp l'idée :-)
>
> je ne sais pas si c'est facile Í  faire très rapidement, parce que :
> - il faut que je définisse des règles pour catégoriser les logs
> (auj dans mon code les logs ne sont divisés qu'en 2 catégories : DEBUG
> et ERROR)

(y a-t-il des règles pour déterminer la catégorie de chaque message ?)

Mon idée, c'est que tu te programmes une fonction genre
« sendlog(niveau,message) »

Et c'est ta fonction sendlog qui va choisir quoi faire de tes logs :
poubelle si c'est pas le bon niveau de logs et envoi dans le cas
contraire.

ok, je comprend mieux :-)

je croyais que tu disais de mettre un tag dans le fichier de log, pour
pouvoir ensuite le relire en filtrant (par ex avec grep), et
éventuellement le répartir en plusieurs fichiers par la suite.

en fait tu dis juste de sélectionner ce qu'on affiche, et que c'est
suffisant au niveau de l'ergonomie pour ne générer qu'un seul fichier de
log.
(dis moi si je me trompe Í  nouveau)

Je ne sais pas si tu utilises un framework, ou si tu définis toutes tes
fonctions, mais il doit bien exister quelque chose.

ça n'est pas une bibliothèque externe, c'est interne Í  RAPID, mais
j'ai 2 procédures : `Debug(Msg);` et `Error(Msg);`, qui sont
l'équivalent de `sendlog(DEBUG,Msg)` et `sendlog(ERROR,Msg)`.

> est-ce que ça convient, d'avoir tous ces tags qui s'affichent dans le
> terminal quand on est en CLI (par ex au moment d'indiquer que les
> arguments sont mauvais) ?

Si c'est une application qui tourne dans un terminal, faut pas que les
logs la rendent inutilisable.

mais si j'ai bien compris, les tags ne sont pas censés se retrouver sur
l'affichage. donc tout va bien :-)

Par exemple, la commande find, si tu
cherches toto.txt avec « find / -name toto.txt » en tant que simple
utilisateur, tu vas avoir l'écran rempli d'erreurs des répertoires que
tu n'as pas le droit de lire. et s'il y a une réponse positive, tu ne
vas pas la voir. Alors tu vas plutÍ´t faire ta recherche avec un
« find / -name toto.txt 2> /dev/null ».

(je n'avais pas encore eu le temps de demander comment faire ça,
merci :-)) )

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

Thomas <fantome.forums.tDeContes@free.fr.invalid> wrote:

configure est tout un environnement Í  son (autoconf), qui génère tout
y.c. Makefile.

je ne comprend pas ...
peux tu reformuler stp ? :-)

Une introduction se trouve ici:

https://fr.wikipedia.org/wiki/Autoconf