gérer des fichiers log

Thomas

17/07/2021 à 00:32

In article <60f1f573$0$27440$,
Nicolas George <nicolas$ wrote:

Thomas , dans le message
, a écritÂ :
le pb, c'est que je ne pose pas la question du point de vue d'un
administrateur, mais du point de vue du développeur d'un logiciel
spécifique, qui essaye d'être le plus portable possible

Ce n'était pas clair *du tout*.

ah ? désolé, je croyais avoir précisé ça suffisamment dans

comment le logiciel devrais faire avec les logs, pour te permettre Í toi
administrateur d'avoir la vie la plus agréable possible si tu
l'installes un jour sur ta machine ?

Tu envoies tes logs sur stdout et tu le laisse se débrouiller.

merci, tu réponds Í qques unes des questions de l'autre msg, du coup :-)
ça amène les questions suivantes :
1
j'ai 2 fichiers de logs : debug et errors
est ce que j'envoie le debug sur stdout et les errors sur stderr ?
2
actuellement, les errors sont tjr loggées dans le fichier,
mais selon les circonstances elles sont soit affichées dans l'interface
graphique, soit envoyées sur stdout.
est ce que, pour que tu puisses en faire ce que tu veux,
il faudrait que je les envoie inconditionnellement sur stdout, comme le
fichier,
peu importe que je les affiche en plus dans l'interface graphique ou pas?
3
comme je n'ai pas ton savoir en matière de gestion des logs, j'ai eu le
réflexe d'ajouter la création des fichiers de logs.
est ce que c'est qqch qui risque de t'embêter, en te mettant dans les
pattes des fichiers de logs lÍ oÍ¹ t'en veux pas ?
--
RAPID maintainer
http://savannah.nongnu.org/projects/rapid/

Nicolas George

17/07/2021 à 09:45

Thomas , dans le message
, a écritÂ :

ah ? désolé, je croyais avoir précisé ça suffisamment dans

Tu as dit que c'était un logiciel autonome, pas que la question portait sur
sa conception plutÍ´t que son utilisation.

j'ai 2 fichiers de logs : debug et errors
est ce que j'envoie le debug sur stdout et les errors sur stderr ?

Ça dépend de certains détails. Cf. ci-dessous.

mais selon les circonstances elles sont soit affichées dans l'interface
graphique, soit envoyées sur stdout.

Wait... What?!?
Si tu as une interface graphique qui a aussi des logs, tu as un énorme
problème de conception qu'il faut corriger.

Marc SCHAEFER

17/07/2021 à 12:36

Thomas wrote:

comment le logiciel devrais faire avec les logs, pour te permettre Í toi
administrateur d'avoir la vie la plus agréable possible si tu
l'installes un jour sur ta machine ?

Je vois deux options:
- s'il est intégré Í ma distribution (Debian), alors tu n'as rien
de spécial Í faire: cela sera le packager/intégrateur qui gérera
ce genre de choses pour que cela soit cohérent avec les conventions
de la distribution
- si c'est un logiciel que je dois installer Í la main (package ou
archive tar.gz), alors, le plus simple est que le fichier README
ou INSTALL explique l'installation et qu'un fichier
de configuration existe et soit documenté (p.ex. avec des
commentaires Í l'intérieur) pour choisir le lieu oÍ¹ les logs
sont stockés
évidemment qu'un fichier de configuration bien documenté
aidera le packager/intégrateur Í l'intégrer dans la
distribution

(par ex : utiliser ".log" comme extension)

Le fichier de configuration pourrait p.ex. contenir:
# par défaut, stocke les logs dans le répertoire courant du
# lancement du logiciel; si vous le lancez comme daemon, il
# est recommandé de mettre ce log dans /var/log/APPLICATION/general.log
# (avec les permissions adéquates)
general_log=general.log
# similaire
error_log=error.log
Ce fichier de configuration, le plus facile, c'est de le donner en
argument au lancement du programme, plutÍ´t que de présupposer des
choses sur l'emplacement des fichiers. Et c'est ce fichier de
configuration qui configurera l'emplacement des journaux et, si
nécessaire, des bibliothèques, templates, binaires etc de
l'application.

Marc SCHAEFER

17/07/2021 à 12:37

Nicolas George <nicolas$ wrote:

Tu envoies tes logs sur stdout et tu le laisse se débrouiller.

C'est aussi une option (avec les erreurs sur stderr). Ainsi
l'intégrateur n'a qu'Í créer un wrapper script.

Marc SCHAEFER

17/07/2021 à 12:40

Thomas wrote:

comme on a des fois des extensions imbriquées, par ex .tar.gz :
est ce qu'il vaut mieux insérer les chiffres avant le 1er point du nom
du fichier, plutÍ´t qu'avant le dernier ?
ou est ce qu'il y a des cas que je ne connais pas, oÍ¹ ça pourrait poser
des pbs ?

Je dirais que sous UNIX, les extensions sont une information Í
l'utilisateur en général, totalement optionnelle.
Il y a des exceptions: p.ex. présupposés de make ou du compilateur sur
.{c,h,cpp,o,a}, et les interfaces graphiques, si elles ont tendance Í
utiliser plutÍ´t un typage MIME dynamique (style file(1)), peuvent aussi
associer des applications aux "extensions".
Je n'aurais par exemple aucun problème, ni mon programme tar, avec un
fichier qui s'appellerait
blala.42.22.tar.gz
même si la convention UNIX est plutÍ´t:
application-VERSION.tar.gz
exemple:
tar-1.2.3.4.tar.gz

Thomas

17/07/2021 à 18:43

In article <scuc3a$u25$,
Marc SCHAEFER wrote:

Thomas wrote:
comme on a des fois des extensions imbriquées, par ex .tar.gz :
est ce qu'il vaut mieux insérer les chiffres avant le 1er point du nom
du fichier, plutÍ´t qu'avant le dernier ?
ou est ce qu'il y a des cas que je ne connais pas, oÍ¹ ça pourrait poser
des pbs ?

Je dirais que sous UNIX, les extensions sont une information Í
l'utilisateur en général, totalement optionnelle.

ah bon ? je croyais que c'était qqch d'assez important au contraire.
tu dis ça peut être en comparaison de windows ou dos.
je connais très mal ces systèmes.
au contraire, j'ai connu les macs Í partir du mac+ (j'avais 10 ans) et
son "système 6" si je me souviens bien,
et dessus, les extensions n'existaient pas.

Il y a des exceptions: p.ex. présupposés de make ou du compilateur sur
.{c,h,cpp,o,a}, et les interfaces graphiques, si elles ont tendance Í
utiliser plutÍ´t un typage MIME dynamique (style file(1)), peuvent aussi
associer des applications aux "extensions".

sur mon mac plus récent, quand je donne un fichier en ".log.2" Í
TextWrangler, il croit que c'est une page de man.

Je n'aurais par exemple aucun problème, ni mon programme tar, avec un
fichier qui s'appellerait
blala.42.22.tar.gz

ça me parait logique :
tar gère le ".gz", ensuite le ".tar", ensuite s'il y a d'autres
extensions imbriquées ça n'est plus son affaire.
tandis que moi, en fait ce que je veux, c'est concatener qqch au nom de
base, sans casser d'extension imbriquée qq soit leur nombre.

même si la convention UNIX est plutÍ´t:
application-VERSION.tar.gz
exemple:
tar-1.2.3.4.tar.gz

si je te suis bien, dans ton 1er exemple :
application = blala
VERSION = 42.22
et donc son nom normalisé serais plutÍ´t
blala-42.22.tar.gz
que
blala.42.22.tar.gz
dans les 2 cas, chercher le 1er point ne marche pas, et le dernier non
plus :-(
une suggestion ?
Í ton avis, est ce que je devrais aussi utiliser "." comme séparateur ?
--
RAPID maintainer
http://savannah.nongnu.org/projects/rapid/

In article <scuc3a$u25$4@shakotay.alphanet.ch>,
Marc SCHAEFER <schaefer@alphanet.ch> wrote:

Thomas <fantome.forums.tDeContes@free.fr.invalid> wrote:
> comme on a des fois des extensions imbriquées, par ex .tar.gz :
> est ce qu'il vaut mieux insérer les chiffres avant le 1er point du nom
> du fichier, plutÍ´t qu'avant le dernier ?
> ou est ce qu'il y a des cas que je ne connais pas, oÍ¹ ça pourrait poser
> des pbs ?

Je dirais que sous UNIX, les extensions sont une information Í
l'utilisateur en général, totalement optionnelle.

ah bon ? je croyais que c'était qqch d'assez important au contraire.

tu dis ça peut être en comparaison de windows ou dos.
je connais très mal ces systèmes.

au contraire, j'ai connu les macs Í partir du mac+ (j'avais 10 ans) et
son "système 6" si je me souviens bien,
et dessus, les extensions n'existaient pas.

Il y a des exceptions: p.ex. présupposés de make ou du compilateur sur
.{c,h,cpp,o,a}, et les interfaces graphiques, si elles ont tendance Í
utiliser plutÍ´t un typage MIME dynamique (style file(1)), peuvent aussi
associer des applications aux "extensions".

sur mon mac plus récent, quand je donne un fichier en ".log.2" Í
TextWrangler, il croit que c'est une page de man.

Je n'aurais par exemple aucun problème, ni mon programme tar, avec un
fichier qui s'appellerait

blala.42.22.tar.gz

ça me parait logique :
tar gère le ".gz", ensuite le ".tar", ensuite s'il y a d'autres
extensions imbriquées ça n'est plus son affaire.

tandis que moi, en fait ce que je veux, c'est concatener qqch au nom de
base, sans casser d'extension imbriquée qq soit leur nombre.

même si la convention UNIX est plutÍ´t:

application-VERSION.tar.gz

exemple:

tar-1.2.3.4.tar.gz

si je te suis bien, dans ton 1er exemple :
application = blala
VERSION = 42.22

et donc son nom normalisé serais plutÍ´t
blala-42.22.tar.gz
que
blala.42.22.tar.gz

dans les 2 cas, chercher le 1er point ne marche pas, et le dernier non
plus :-(

une suggestion ?

Í ton avis, est ce que je devrais aussi utiliser "." comme séparateur ?

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

Vous avez filtré cet utilisateur ! Consultez son message

Thomas

17/07/2021 à 20:44

In article <scubs2$u25$,
Marc SCHAEFER wrote:

Thomas wrote:
comment le logiciel devrais faire avec les logs, pour te permettre Í toi
administrateur d'avoir la vie la plus agréable possible si tu
l'installes un jour sur ta machine ?

Je vois deux options:

je souhaite que mon logiciel soit adapté aux 2.

- s'il est intégré Í ma distribution (Debian), alors tu n'as rien
de spécial Í faire: cela sera le packager/intégrateur qui gérera
ce genre de choses pour que cela soit cohérent avec les conventions
de la distribution

il y a quand même un minimum pour ne pas lui rendre la vie trop difficile

- si c'est un logiciel que je dois installer Í la main (package ou
archive tar.gz), alors, le plus simple est que le fichier README
ou INSTALL explique l'installation

ça serais chouette que des gens d'ici veuillent bien relire ces
fichiers, pour vérifier si tout est compréhensible :-)
mais je prévois de les convertir en Markdown, donc ça sera surement plus
agréable Í relire pour vous si vous attendez que ça soit fait.

et qu'un fichier
de configuration existe et soit documenté (p.ex. avec des
commentaires Í l'intérieur) pour choisir le lieu oÍ¹ les logs
sont stockés

l'architecture proposée ne me déplaÍ®t pas,
le gros pb que j'ai avec cette proposition, c'est que :
- il n'y a pas de base pour ça dans le logiciel (donc j'ai tout Í créer),
- l'analyse de texte me débecte (donc si je peux l'éviter ...)
mais si je comprend bien, la proposition de Nicolas te convient ?
rien de plus simple, et en plus c'est (presque) déjÍ fait !

évidemment qu'un fichier de configuration bien documenté
aidera le packager/intégrateur Í l'intégrer dans la
distribution

:-)
faut il documenter la nécessité de gérer stdout et stderr ?

(par ex : utiliser ".log" comme extension)

Le fichier de configuration pourrait p.ex. contenir:
# par défaut, stocke les logs dans le répertoire courant du
# lancement du logiciel;

est ce que tu parles du répertoire courant (pwd), ou du répertoire
contenant le binaire du logiciel qu'on lance ?
ce que je comptais faire, c'est :
- partir du répertoire contenant le binaire
- ajouter un sous-répertoire "log"
- vu la proposition de gérer ça majoritairement avec stdout et stderr,
en cas d'erreur quelconque Í l'écriture des logs, l'ignorer
silencieusement, tout simplement.

si vous le lancez comme daemon, il
# est recommandé de mettre ce log dans /var/log/APPLICATION/general.log
# (avec les permissions adéquates)

en principe ça ne sera jamais un daemon, puisque c'est une application
graphique, qui peut aussi occasionnellement être utilisée en ligne de
commande
(une autre question subsidiaire est : est ce courant, ou est ce
recommandé de faire 2 binaires séparés pour chacun des usages ?)

general_log=general.log
# similaire
error_log=error.log

est ce que le general c'est le debug activé tout le temps, ou est ce que
ce sont 2 choses différentes ?

Ce fichier de configuration, le plus facile, c'est de le donner en
argument au lancement du programme,

est ce que c'est qqch qui marche aussi avec une application graphique ?

plutÍ´t que de présupposer des
choses sur l'emplacement des fichiers. Et c'est ce fichier de
configuration qui configurera l'emplacement des journaux et, si
nécessaire, des bibliothèques, templates, binaires etc de
l'application.

c'est sur que si on fait ça, ça permet de résoudre cette série de
questions d'un seul coup !
merci pour l'indication :-)
--
RAPID maintainer
http://savannah.nongnu.org/projects/rapid/

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

Thomas <fantome.forums.tDeContes@free.fr.invalid> wrote:
> comment le logiciel devrais faire avec les logs, pour te permettre Í toi
> administrateur d'avoir la vie la plus agréable possible si tu
> l'installes un jour sur ta machine ?

Je vois deux options:

je souhaite que mon logiciel soit adapté aux 2.

- s'il est intégré Í ma distribution (Debian), alors tu n'as rien
de spécial Í faire: cela sera le packager/intégrateur qui gérera
ce genre de choses pour que cela soit cohérent avec les conventions
de la distribution

il y a quand même un minimum pour ne pas lui rendre la vie trop difficile

- si c'est un logiciel que je dois installer Í la main (package ou
archive tar.gz), alors, le plus simple est que le fichier README
ou INSTALL explique l'installation

ça serais chouette que des gens d'ici veuillent bien relire ces
fichiers, pour vérifier si tout est compréhensible :-)

mais je prévois de les convertir en Markdown, donc ça sera surement plus
agréable Í relire pour vous si vous attendez que ça soit fait.

et qu'un fichier
de configuration existe et soit documenté (p.ex. avec des
commentaires Í l'intérieur) pour choisir le lieu oÍ¹ les logs
sont stockés

l'architecture proposée ne me déplaÍ®t pas,
le gros pb que j'ai avec cette proposition, c'est que :
- il n'y a pas de base pour ça dans le logiciel (donc j'ai tout Í créer),
- l'analyse de texte me débecte (donc si je peux l'éviter ...)

mais si je comprend bien, la proposition de Nicolas te convient ?
rien de plus simple, et en plus c'est (presque) déjÍ fait !

évidemment qu'un fichier de configuration bien documenté
aidera le packager/intégrateur Í l'intégrer dans la
distribution

:-)
faut il documenter la nécessité de gérer stdout et stderr ?

> (par ex : utiliser ".log" comme extension)

Le fichier de configuration pourrait p.ex. contenir:

# par défaut, stocke les logs dans le répertoire courant du
# lancement du logiciel;

est ce que tu parles du répertoire courant (pwd), ou du répertoire
contenant le binaire du logiciel qu'on lance ?

ce que je comptais faire, c'est :
- partir du répertoire contenant le binaire
- ajouter un sous-répertoire "log"
- vu la proposition de gérer ça majoritairement avec stdout et stderr,
en cas d'erreur quelconque Í l'écriture des logs, l'ignorer
silencieusement, tout simplement.

si vous le lancez comme daemon, il
# est recommandé de mettre ce log dans /var/log/APPLICATION/general.log
# (avec les permissions adéquates)

en principe ça ne sera jamais un daemon, puisque c'est une application
graphique, qui peut aussi occasionnellement être utilisée en ligne de
commande

(une autre question subsidiaire est : est ce courant, ou est ce
recommandé de faire 2 binaires séparés pour chacun des usages ?)

general_log=general.log

# similaire
error_log=error.log

est ce que le general c'est le debug activé tout le temps, ou est ce que
ce sont 2 choses différentes ?

Ce fichier de configuration, le plus facile, c'est de le donner en
argument au lancement du programme,

est ce que c'est qqch qui marche aussi avec une application graphique ?

plutÍ´t que de présupposer des
choses sur l'emplacement des fichiers. Et c'est ce fichier de
configuration qui configurera l'emplacement des journaux et, si
nécessaire, des bibliothèques, templates, binaires etc de
l'application.

c'est sur que si on fait ça, ça permet de résoudre cette série de
questions d'un seul coup !
merci pour l'indication :-)

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

Vous avez filtré cet utilisateur ! Consultez son message

In article <scubs2$u25$,
Marc SCHAEFER wrote:

Thomas wrote:
comment le logiciel devrais faire avec les logs, pour te permettre Í toi
administrateur d'avoir la vie la plus agréable possible si tu
l'installes un jour sur ta machine ?

Je vois deux options:

je souhaite que mon logiciel soit adapté aux 2.

- s'il est intégré Í ma distribution (Debian), alors tu n'as rien
de spécial Í faire: cela sera le packager/intégrateur qui gérera
ce genre de choses pour que cela soit cohérent avec les conventions
de la distribution

il y a quand même un minimum pour ne pas lui rendre la vie trop difficile

- si c'est un logiciel que je dois installer Í la main (package ou
archive tar.gz), alors, le plus simple est que le fichier README
ou INSTALL explique l'installation

ça serais chouette que des gens d'ici veuillent bien relire ces
fichiers, pour vérifier si tout est compréhensible :-)
mais je prévois de les convertir en Markdown, donc ça sera surement plus
agréable Í relire pour vous si vous attendez que ça soit fait.

et qu'un fichier
de configuration existe et soit documenté (p.ex. avec des
commentaires Í l'intérieur) pour choisir le lieu oÍ¹ les logs
sont stockés

l'architecture proposée ne me déplaÍ®t pas,
le gros pb que j'ai avec cette proposition, c'est que :
- il n'y a pas de base pour ça dans le logiciel (donc j'ai tout Í créer),
- l'analyse de texte me débecte (donc si je peux l'éviter ...)
mais si je comprend bien, la proposition de Nicolas te convient ?
rien de plus simple, et en plus c'est (presque) déjÍ fait !

évidemment qu'un fichier de configuration bien documenté
aidera le packager/intégrateur Í l'intégrer dans la
distribution

:-)
faut il documenter la nécessité de gérer stdout et stderr ?

(par ex : utiliser ".log" comme extension)

Le fichier de configuration pourrait p.ex. contenir:
# par défaut, stocke les logs dans le répertoire courant du
# lancement du logiciel;

est ce que tu parles du répertoire courant (pwd), ou du répertoire
contenant le binaire du logiciel qu'on lance ?
ce que je comptais faire, c'est :
- partir du répertoire contenant le binaire
- ajouter un sous-répertoire "log"
- vu la proposition de gérer ça majoritairement avec stdout et stderr,
en cas d'erreur quelconque Í l'écriture des logs, l'ignorer
silencieusement, tout simplement.

si vous le lancez comme daemon, il
# est recommandé de mettre ce log dans /var/log/APPLICATION/general.log
# (avec les permissions adéquates)

en principe ça ne sera jamais un daemon, puisque c'est une application
graphique, qui peut aussi occasionnellement être utilisée en ligne de
commande
(une autre question subsidiaire est : est ce courant, ou est ce
recommandé de faire 2 binaires séparés pour chacun des usages ?)

general_log=general.log
# similaire
error_log=error.log

est ce que le general c'est le debug activé tout le temps, ou est ce que
ce sont 2 choses différentes ?

Ce fichier de configuration, le plus facile, c'est de le donner en
argument au lancement du programme,

est ce que c'est qqch qui marche aussi avec une application graphique ?

plutÍ´t que de présupposer des
choses sur l'emplacement des fichiers. Et c'est ce fichier de
configuration qui configurera l'emplacement des journaux et, si
nécessaire, des bibliothèques, templates, binaires etc de
l'application.

c'est sur que si on fait ça, ça permet de résoudre cette série de
questions d'un seul coup !
merci pour l'indication :-)
--
RAPID maintainer
http://savannah.nongnu.org/projects/rapid/

Thomas

17/07/2021 à 22:15

In article <60f28ab3$0$3745$,
Nicolas George <nicolas$ wrote:

Thomas , dans le message
, a écritÂ :
ah ? désolé, je croyais avoir précisé ça suffisamment dans

Tu as dit que c'était un logiciel autonome, pas que la question portait sur
sa conception plutÍ´t que son utilisation.

ah, désolé, je vais essayer d'en tenir compte pour les prochaines fois
j'essaye de faire attention aux détails le plus possible (en essayant
aussi d'avoir des limites),
avec l'idée qu'un pb pas forcément très important tout de suite, s'il
est facile Í traiter pour peu qu'on s'en occupe, sera un pb qu'on n'aura
pas dans les pattes plus tard.
mais je n'échappe pas Í un phénomène, qui est la relativité du
référentiel définissant ce qui est évident pour chacun ...
(faut t il faire le lien avec "ce qui est évident ne peut pas être
expliqué" ?)
donc il y a des choses que tu as besoin que je t'indique, et je n'ai pas
l'idée de ce besoin parce que pour moi c'est évident.
j'en profite pour préciser :
pour moi, "autonome" voulait dire que le logiciel n'est pas livré avec
son OS autour, cad "portable" en fait (je crois)
donc chacun dois pouvoir telecharger les sources et le compiler (et
bientÍ´t l'installer),
et le logiciel doit Í la fois pouvoir "y retrouver ses petits", et ne
pas salir le FS hÍ´te en mettant toutes sortes de fichiers n'importe oÍ¹,
être agréable Í son utilisateur en en faisant assez mais pas trop, etc...
(est ce que pour toi ça voulait dire autre chose ?)

j'ai 2 fichiers de logs : debug et errors
est ce que j'envoie le debug sur stdout et les errors sur stderr ?

Ça dépend de certains détails. Cf. ci-dessous.

ok, on va voir ça.

mais selon les circonstances elles sont soit affichées dans l'interface
graphique, soit envoyées sur stdout.

Wait... What?!?
Si tu as une interface graphique qui a aussi des logs, tu as un énorme
problème de conception qu'il faut corriger.

mon intuition me dit que je n'ai pas d'énorme problème de conception,
mais un énorme problème de communication avec toi ;-)
qu'as tu compris ?
que le "toolkit" que j'utilise pour l'interface graphique génère
lui-même des logs ?
non, ce que je disais, c'est que les erreurs, au moment de leur
traitement, peuvent être affichées dans l'interface graphique, plutÍ´t
qu'envoyées sur stdout.
pour préciser :
- tout ceci est un choix du mainteneur précédent, et je suis lÍ pour
corriger ce qui n'est pas fait dans les règles de l'art, sur vos
indications.
- comme dit dans ma réponse Í Marc, le logiciel est une application
graphique, qui peut aussi occasionnellement être utilisée en ligne de
commande.
- dans le cas général, il est utilisé comme une application graphique,
et les erreurs sont affichées dans l'interface graphique, dans une boite
de dialogue avec un bouton "ok" Í cliquer des qu'on a lu l'erreur.
dans ce cas lÍ , elles sont écrites dans le fichier de log mais pas
envoyées sur stdout.
- dans le cas oÍ¹ on l'utilise en ligne de commande,
les erreurs sont envoyées sur stdout.
dans ce cas lÍ , elles sont ecrites dans le fichier de log mais pas
affichées dans l'interface graphique.
je te propose qu'avant de revenir Í mes questions, tu me dises s'il
reste des points pas clairs quant Í la description de l'état des choses
:-)
--
RAPID maintainer
http://savannah.nongnu.org/projects/rapid/

In article <60f28ab3$0$3745$426a74cc@news.free.fr>,
Nicolas George <nicolas$george@salle-s.org> wrote:

Thomas , dans le message
<fantome.forums.tDeContes-BC1C13.00324017072021@news.free.fr>, a écritÂ :
> ah ? désolé, je croyais avoir précisé ça suffisamment dans
> <fantome.forums.tDeContes-BC749E.21034606072021@news.free.fr>

Tu as dit que c'était un logiciel autonome, pas que la question portait sur
sa conception plutÍ´t que son utilisation.

ah, désolé, je vais essayer d'en tenir compte pour les prochaines fois

j'essaye de faire attention aux détails le plus possible (en essayant
aussi d'avoir des limites),
avec l'idée qu'un pb pas forcément très important tout de suite, s'il
est facile Í traiter pour peu qu'on s'en occupe, sera un pb qu'on n'aura
pas dans les pattes plus tard.

mais je n'échappe pas Í un phénomène, qui est la relativité du
référentiel définissant ce qui est évident pour chacun ...
(faut t il faire le lien avec "ce qui est évident ne peut pas être
expliqué" ?)
donc il y a des choses que tu as besoin que je t'indique, et je n'ai pas
l'idée de ce besoin parce que pour moi c'est évident.

j'en profite pour préciser :

pour moi, "autonome" voulait dire que le logiciel n'est pas livré avec
son OS autour, cad "portable" en fait (je crois)

donc chacun dois pouvoir telecharger les sources et le compiler (et
bientÍ´t l'installer),
et le logiciel doit Í la fois pouvoir "y retrouver ses petits", et ne
pas salir le FS hÍ´te en mettant toutes sortes de fichiers n'importe oÍ¹,
être agréable Í son utilisateur en en faisant assez mais pas trop, etc...

(est ce que pour toi ça voulait dire autre chose ?)

> j'ai 2 fichiers de logs : debug et errors
>
> est ce que j'envoie le debug sur stdout et les errors sur stderr ?

Ça dépend de certains détails. Cf. ci-dessous.

ok, on va voir ça.

> mais selon les circonstances elles sont soit affichées dans l'interface
> graphique, soit envoyées sur stdout.

Wait... What?!?

Si tu as une interface graphique qui a aussi des logs, tu as un énorme
problème de conception qu'il faut corriger.

mon intuition me dit que je n'ai pas d'énorme problème de conception,
mais un énorme problème de communication avec toi ;-)

qu'as tu compris ?
que le "toolkit" que j'utilise pour l'interface graphique génère
lui-même des logs ?

non, ce que je disais, c'est que les erreurs, au moment de leur
traitement, peuvent être affichées dans l'interface graphique, plutÍ´t
qu'envoyées sur stdout.

pour préciser :

- tout ceci est un choix du mainteneur précédent, et je suis lÍ pour
corriger ce qui n'est pas fait dans les règles de l'art, sur vos
indications.

- comme dit dans ma réponse Í Marc, le logiciel est une application
graphique, qui peut aussi occasionnellement être utilisée en ligne de
commande.

- dans le cas général, il est utilisé comme une application graphique,
et les erreurs sont affichées dans l'interface graphique, dans une boite
de dialogue avec un bouton "ok" Í cliquer des qu'on a lu l'erreur.
dans ce cas lÍ , elles sont écrites dans le fichier de log mais pas
envoyées sur stdout.

- dans le cas oÍ¹ on l'utilise en ligne de commande,
les erreurs sont envoyées sur stdout.
dans ce cas lÍ , elles sont ecrites dans le fichier de log mais pas
affichées dans l'interface graphique.

je te propose qu'avant de revenir Í mes questions, tu me dises s'il
reste des points pas clairs quant Í la description de l'état des choses
:-)

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

Vous avez filtré cet utilisateur ! Consultez son message

In article <60f28ab3$0$3745$,
Nicolas George <nicolas$ wrote:

Thomas , dans le message
, a écritÂ :
ah ? désolé, je croyais avoir précisé ça suffisamment dans

Tu as dit que c'était un logiciel autonome, pas que la question portait sur
sa conception plutÍ´t que son utilisation.

ah, désolé, je vais essayer d'en tenir compte pour les prochaines fois
j'essaye de faire attention aux détails le plus possible (en essayant
aussi d'avoir des limites),
avec l'idée qu'un pb pas forcément très important tout de suite, s'il
est facile Í traiter pour peu qu'on s'en occupe, sera un pb qu'on n'aura
pas dans les pattes plus tard.
mais je n'échappe pas Í un phénomène, qui est la relativité du
référentiel définissant ce qui est évident pour chacun ...
(faut t il faire le lien avec "ce qui est évident ne peut pas être
expliqué" ?)
donc il y a des choses que tu as besoin que je t'indique, et je n'ai pas
l'idée de ce besoin parce que pour moi c'est évident.
j'en profite pour préciser :
pour moi, "autonome" voulait dire que le logiciel n'est pas livré avec
son OS autour, cad "portable" en fait (je crois)
donc chacun dois pouvoir telecharger les sources et le compiler (et
bientÍ´t l'installer),
et le logiciel doit Í la fois pouvoir "y retrouver ses petits", et ne
pas salir le FS hÍ´te en mettant toutes sortes de fichiers n'importe oÍ¹,
être agréable Í son utilisateur en en faisant assez mais pas trop, etc...
(est ce que pour toi ça voulait dire autre chose ?)

j'ai 2 fichiers de logs : debug et errors
est ce que j'envoie le debug sur stdout et les errors sur stderr ?

Ça dépend de certains détails. Cf. ci-dessous.

ok, on va voir ça.

mais selon les circonstances elles sont soit affichées dans l'interface
graphique, soit envoyées sur stdout.

Wait... What?!?
Si tu as une interface graphique qui a aussi des logs, tu as un énorme
problème de conception qu'il faut corriger.

mon intuition me dit que je n'ai pas d'énorme problème de conception,
mais un énorme problème de communication avec toi ;-)
qu'as tu compris ?
que le "toolkit" que j'utilise pour l'interface graphique génère
lui-même des logs ?
non, ce que je disais, c'est que les erreurs, au moment de leur
traitement, peuvent être affichées dans l'interface graphique, plutÍ´t
qu'envoyées sur stdout.
pour préciser :
- tout ceci est un choix du mainteneur précédent, et je suis lÍ pour
corriger ce qui n'est pas fait dans les règles de l'art, sur vos
indications.
- comme dit dans ma réponse Í Marc, le logiciel est une application
graphique, qui peut aussi occasionnellement être utilisée en ligne de
commande.
- dans le cas général, il est utilisé comme une application graphique,
et les erreurs sont affichées dans l'interface graphique, dans une boite
de dialogue avec un bouton "ok" Í cliquer des qu'on a lu l'erreur.
dans ce cas lÍ , elles sont écrites dans le fichier de log mais pas
envoyées sur stdout.
- dans le cas oÍ¹ on l'utilise en ligne de commande,
les erreurs sont envoyées sur stdout.
dans ce cas lÍ , elles sont ecrites dans le fichier de log mais pas
affichées dans l'interface graphique.
je te propose qu'avant de revenir Í mes questions, tu me dises s'il
reste des points pas clairs quant Í la description de l'état des choses
:-)
--
RAPID maintainer
http://savannah.nongnu.org/projects/rapid/

Marc SCHAEFER

18/07/2021 à 09:29

Thomas wrote:

est ce que tu parles du répertoire courant (pwd), ou du répertoire

oui

contenant le binaire du logiciel qu'on lance ?

non, c'est risqué / compliqué sous UNIX

Marc SCHAEFER

18/07/2021 à 09:30

Thomas wrote:

dans les 2 cas, chercher le 1er point ne marche pas, et le dernier non
plus :-(

Quel est l'objectif?

gérer des fichiers log

10 réponses

Veuillez sélectionner un problème