Path: ...!weretis.net!feeder6.news.weretis.net!feeder8.news.weretis.net!proxad.net!feeder1-2.proxad.net!cleanfeed2-a.proxad.net!nnrp1-1.free.fr!not-for-mail
From: Thomas <fantome.forums.tDeContes@free.fr.invalid>
Newsgroups: fr.comp.os.unix
Mail-Copies-To: nobody
Subject: Re: =?UTF-8?Q?g=C3=A9rer?= des fichiers log
References: <fantome.forums.tDeContes-AD48E3.21414905072021@news.free.fr> <scubs2$u25$2@shakotay.alphanet.ch> <fantome.forums.tDeContes-F23835.20444917072021@news.free.fr> <sd0l91$b4m$1@shakotay.alphanet.ch> <fantome.forums.tDeContes-130E7D.23050920072021@news.free.fr> <sd8faa$8ac$1@shakotay.alphanet.ch> <fantome.forums.tDeContes-433B13.01575723072021@news.free.fr> <sddoan$flh$1@shakotay.alphanet.ch> <fantome.forums.tDeContes-5442BA.19235419092021@news.free.fr> <si9urh$mad$1@shakotay.alphanet.ch> <fantome.forums.tDeContes-D7C707.17401124092021@news.free.fr> <slrnsks8om.83t.sc@scarpet42p.localdomain> <fantome.forums.tDeContes-AD18A9.03233926092021@news.free.fr> <slrnsl18t8.29t.sc@scarpet42p.localdomain>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
User-Agent: MT-NewsWatcher/3.5.3b3 (Intel Mac OS X)
Date: Mon, 27 Sep 2021 17:33:06 +0200
Message-ID: <fantome.forums.tDeContes-CB5B35.17330627092021@news.free.fr>
Lines: 176
Organization: Guest of ProXad - France
NNTP-Posting-Date: 27 Sep 2021 17:33:07 CEST
NNTP-Posting-Host: 91.175.52.121
X-Trace: 1632756787 news-2.free.fr 3718 91.175.52.121:16312
X-Complaints-To: abuse@proxad.net
Bytes: 9237

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/