X-Received: by 2002:a05:600c:1e08:b0:3b4:8fef:d63c with SMTP id ay8-20020a05600c1e0800b003b48fefd63cmr11630055wmb.158.1663371212282; Fri, 16 Sep 2022 16:33:32 -0700 (PDT) Path: ...!news-out.google.com!nntp.google.com!proxad.net!feeder1-2.proxad.net!cleanfeed1-a.proxad.net!nnrp1-1.free.fr!not-for-mail From: Thomas Newsgroups: fr.comp.os.unix Mail-Copies-To: nobody Subject: tags pour les logs References: MIME-Version: 1.0 User-Agent: MT-NewsWatcher/3.5.3b3 (Intel Mac OS X) Date: Sat, 17 Sep 2022 01:33:31 +0200 Lines: 60 Message-ID: <632507cc$0$31538$426a34cc@news.free.fr> Organization: Guest of ProXad - France NNTP-Posting-Date: 17 Sep 2022 01:33:32 CEST NNTP-Posting-Host: 91.175.52.121 X-Trace: 1663371212 news-4.free.fr 31538 91.175.52.121:5022 X-Complaints-To: abuse@proxad.net Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Bytes: 4345 In article , Stéphane CARPENTIER wrote: > Le 26-09-2021, Thomas a écrit : > > In article , > > Stéphane CARPENTIER wrote: > >> 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) au fur et à mesure que je parcours mon code, je vois de mieux en mieux comment il faudrait que je repartisse les msgs dans chaque catégorie. j'aurais même envie d'ajouter : - les erreurs critiques, quand le logiciel se retrouve dans un état tel qu'il est contraint de se terminer immédiatement, - les erreurs d'usage, dues à un mesusage de l'utilisateur, - éventuellement, les erreurs dues à des données d'entrée incohérentes, si elles nécessitent d'être distinguées des simples bugs de programme. est-ce une mauvaise idée ? > > - 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) ? > > Si c'est une application qui tourne dans un terminal, faut pas que les > logs la rendent inutilisable. > C'est pareil pour ton > application, il faut qu'elle soit souple. j'ai pas avancé là dessus : je ne sais pas comment faire ça bien. là où je butte c'est que les sorties standard devraient à la fois servir pour la production de logs, avec tags & horodatage, et à la fois ne pas être surchargées, pour le cas où l'utilisateur afficherais ça dans son terminal. -- RAPID maintainer http://savannah.nongnu.org/projects/rapid/