Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > fr.comp.os.unix > #7714 > unrolled thread

gérer des fichiers log

Back to article view | Back to fr.comp.os.unix

Contents

  gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-07-05 21:41 +0200
    Re: gérer des fichiers log yamo' <yamo@beurdin.invalid> - 2021-07-06 09:44 +0200
      Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-07-06 14:15 +0200
      Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-07-16 22:50 +0200
    Re: gérer des fichiers log Nicolas George <nicolas$george@salle-s.org> - 2021-07-06 13:04 +0000
      Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-07-06 21:03 +0200
        Re: gérer des fichiers log Nicolas George <nicolas$george@salle-s.org> - 2021-07-06 19:52 +0000
          Re: gérer des fichiers log Marc SCHAEFER <schaefer@alphanet.ch> - 2021-07-06 20:11 +0000
            Re: gérer des fichiers log Nicolas George <nicolas$george@salle-s.org> - 2021-07-07 00:42 +0000
              Re: gérer des fichiers log Marc SCHAEFER <schaefer@alphanet.ch> - 2021-07-07 06:03 +0000
                Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-07-16 23:03 +0200
                  Re: gérer des fichiers log Nicolas George <nicolas$george@salle-s.org> - 2021-07-16 21:09 +0000
                    Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-07-17 00:32 +0200
                      Re: gérer des fichiers log Nicolas George <nicolas$george@salle-s.org> - 2021-07-17 07:45 +0000
                        Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-07-17 22:15 +0200
                    Re: gérer des fichiers log Marc SCHAEFER <schaefer@alphanet.ch> - 2021-07-17 10:37 +0000
                  Re: gérer des fichiers log Marc SCHAEFER <schaefer@alphanet.ch> - 2021-07-17 10:36 +0000
                    Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-07-17 20:44 +0200
                      Re: gérer des fichiers log Marc SCHAEFER <schaefer@alphanet.ch> - 2021-07-18 07:29 +0000
                        Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-07-20 23:05 +0200
                          Re: gérer des fichiers log Marc SCHAEFER <schaefer@alphanet.ch> - 2021-07-21 06:36 +0000
                            Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-07-23 01:58 +0200
                              Re: gérer des fichiers log Marc SCHAEFER <schaefer@alphanet.ch> - 2021-07-23 06:41 +0000
                                Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-09-19 19:23 +0200
                                  Re: gérer des fichiers log Marc SCHAEFER <schaefer@alphanet.ch> - 2021-09-20 12:29 +0000
                                    Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-09-24 17:40 +0200
                                      Re: gérer des fichiers log Marc SCHAEFER <schaefer@alphanet.ch> - 2021-09-24 17:21 +0000
                                        Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-09-26 01:15 +0200
                                          Re: gérer des fichiers log Marc SCHAEFER <schaefer@alphanet.ch> - 2021-09-26 14:24 +0000
                                            Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-09-28 22:02 +0200
                                      Re: gérer des fichiers log Stéphane CARPENTIER <sc@fiat-linux.fr> - 2021-09-24 19:12 +0000
                                        Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-09-26 03:23 +0200
                                          Re: gérer des fichiers log Stéphane CARPENTIER <sc@fiat-linux.fr> - 2021-09-26 16:45 +0000
                                            Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-09-27 17:33 +0200
                                              Re: gérer des fichiers log Stéphane CARPENTIER <sc@fiat-linux.fr> - 2021-10-01 16:54 +0000
                                                Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-10-22 23:41 +0200
                                                  Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-12-19 19:19 +0100
                                                    Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-12-28 12:18 +0100
                                                    Re: gérer des fichiers log Stéphane CARPENTIER <sc@fiat-linux.fr> - 2021-12-28 15:56 +0000
                                                      Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2022-01-02 00:54 +0100
                                            tags pour les logs Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2022-09-17 01:33 +0200
          Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-07-17 00:06 +0200
            Re: gérer des fichiers log Marc SCHAEFER <schaefer@alphanet.ch> - 2021-07-17 10:40 +0000
              Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-07-17 18:43 +0200
                Re: gérer des fichiers log Marc SCHAEFER <schaefer@alphanet.ch> - 2021-07-18 07:30 +0000
                  Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-07-20 21:23 +0200
                    Re: gérer des fichiers log Marc SCHAEFER <schaefer@alphanet.ch> - 2021-07-20 19:32 +0000
                      Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-07-21 00:39 +0200
                        Re: gérer des fichiers log Marc SCHAEFER <schaefer@alphanet.ch> - 2021-07-21 06:42 +0000
                          Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-07-22 20:41 +0200
                            Re: gérer des fichiers log Marc SCHAEFER <schaefer@alphanet.ch> - 2021-07-22 18:58 +0000
                              Re: gérer des fichiers log Stephane Tougard <stephane@unices.org> - 2021-07-22 19:25 +0000
                                Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-07-23 03:03 +0200
                                  Re: gérer des fichiers log Stephane Tougard <stephane@unices.org> - 2021-07-23 04:07 +0000
                                    Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-09-23 01:41 +0200
                                  Re: gérer des fichiers log Marc SCHAEFER <schaefer@alphanet.ch> - 2021-07-23 06:49 +0000
                                    Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-09-19 21:11 +0200
                                      Re: gérer des fichiers log Marc SCHAEFER <schaefer@alphanet.ch> - 2021-09-20 12:43 +0000
                                        Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-09-24 19:12 +0200
                                          Re: gérer des fichiers log Marc SCHAEFER <schaefer@alphanet.ch> - 2021-09-24 17:36 +0000
                                            Re: gérer des fichiers log Stéphane CARPENTIER <sc@fiat-linux.fr> - 2021-09-24 19:24 +0000
                                            Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-09-25 23:40 +0200
                              Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-07-23 02:32 +0200
                                Re: gérer des fichiers log Marc SCHAEFER <schaefer@alphanet.ch> - 2021-07-23 06:59 +0000
                                  Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-09-19 19:23 +0200
                                    Re: gérer des fichiers log Marc SCHAEFER <schaefer@alphanet.ch> - 2021-09-20 12:40 +0000
                                      Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-09-25 21:04 +0200
                                        Re: gérer des fichiers log Marc SCHAEFER <schaefer@alphanet.ch> - 2021-09-26 14:30 +0000
                                          Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-09-27 15:32 +0200
                                            Re: gérer des fichiers log Marc SCHAEFER <schaefer@alphanet.ch> - 2021-09-27 15:44 +0000
                                          Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2022-09-16 23:25 +0200
                                            Re: gérer des fichiers log Marc SCHAEFER <schaefer@alphanet.ch> - 2022-09-17 05:56 +0000
                                              Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2022-09-17 15:46 +0200
                    Re: gérer des fichiers log Nicolas George <nicolas$george@salle-s.org> - 2021-07-20 20:28 +0000
                      Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-07-20 23:33 +0200
                        Re: gérer des fichiers log Nicolas George <nicolas$george@salle-s.org> - 2021-07-21 15:31 +0000
                          Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-07-22 17:12 +0200
                            Re: gérer des fichiers log Stéphane CARPENTIER <sc@fiat-linux.fr> - 2021-07-24 13:36 +0000
                              Re: gérer des fichiers log Nicolas George <nicolas$george@salle-s.org> - 2021-07-24 14:09 +0000
                                Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-09-23 14:44 +0200
                                  Re: gérer des fichiers log Nicolas George <nicolas$george@salle-s.org> - 2021-09-23 12:54 +0000
                                  Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2022-08-09 20:57 +0200
                              Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2021-09-23 14:38 +0200
    Re: gérer des fichiers log Stephane Tougard <stephane@unices.org> - 2021-07-23 04:03 +0000
    Re: g�rer des fichiers log garkbeda43 <nospam_garkbeda43@gmail.com.invalid> - 2022-06-11 02:27 -0500
      Re: gérer des fichiers log Thomas <fantome.forums.tDeContes@free.fr.invalid> - 2022-07-30 16:42 +0200

Page 3 of 5 — ← Prev page 1 2 [3] 4 5  Next page →

#8016 — tags pour les logs

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:

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

[toc] | [prev] | [next] | [standalone]

#7733

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

> Thomas , dans le message
> <fantome.forums.tDeContes-BC749E.21034606072021@news.free.fr>, a écrit :
> > je crois bon de préciser que je ne parle pas d'administration système, 
> > mais d'un logiciel autonome
> 
> Dans ce cas, il faudrait regarder ce les pratiques autour de ce logiciel.

quand je l'ai repris, il ne générais aucun fichier de log, il les 
affichait seulement à l'écran.

> 
> > est ce que je ne devrais pas tenter de faire gérer les logs par le 
> > logiciel, mais seulement de les placer au bon endroit, et le système 
> > s'en charge automatiquement avec un outil du genre logrotate qui serais 
> > activé par défaut sur les distributions courantes ?
> 
> Tu peux, c'est vraiment toi qui vois.
> 
> Si c'est du Linux récent mainstream, tu auras systemd et journald, qui rend
> ça beaucoup plus facile.

j'ai 1 contrainte dure :
pour être portable, ne pas dépendre de la présence d'un outil pour le 
bon fonctionnement.

ensuite, je souhaite optimiser :
- le confort de l'usager, s'il ne dispose d'aucun autre outil pour gérer 
ses logs,
- le travail que ça me fera : je voudrais quand même éviter de 
réinventer la roue si d'autres font la même chose bcp mieux que moi.


> 
> > sauf que, je viens de penser, on peut combiner les 2 ... 2021-07-06.1
> 
> Bof. Utilise un timestamp plus précis. Si ton logiciel met une seconde à
> s'initialiser, un le timestamp de lancement peut servir à rendre le nom
> unique.

pas de pb pour l'unicité, mais justement, comme il n'y en aura pas bcp, 
je trouve que ça fera bcp de chiffres ...


question sur les extensions, pour le cas où je généraliserais cette 
procédure pour "pousser à coté" un fichier existant :

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 ?


> 
> > ça dépend du gestionnaire de fichiers qu'on utilise :
> > certains reconnaissent les suites de chiffres comme des nombres, et font 
> > le tri en conséquence (par ex Finder sur mac)
> 
> Beurk. Les logiciels qui essaient d'être plus intelligents que moi, cet
> article résume parfaitement ce que j'en pense :
> 
> https://piece-of-a-larger-me.github.io/la_vallee_derangeante_de_l_intelligence
> _artificielle.html

très intéressant :-)
et celui en lien à la fin, aussi !

mais en l'occurrence, les gestionnaires de fichiers qui reconnaissent 
les suites de chiffres comme des nombres sont parfaitement prévisibles.

c'est seulement en tant que développeur que, ce qui est imprévisible, 
c'est "quel sera le gestionnaire de fichiers de l'usager".


> 
> > "bons" c'est relatif (et ça vaut jusqu'à ce que « NG » signifie 
> > "aNcienne Génération ;-) ),
> > mais veux tu simplement dire que les logiciels qui ont « NG » sont 
> > logiquement "meilleurs" que ceux de la génération précédente ?
> 
> Regarde comment je m'appelle ;-Þ

:-D

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

[toc] | [prev] | [next] | [standalone]

#7738

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.

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

[toc] | [prev] | [next] | [standalone]

#7739

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/

[toc] | [prev] | [next] | [standalone]

#7743

Thomas <fantome.forums.tDeContes@free.fr.invalid> wrote:
> dans les 2 cas, chercher le 1er point ne marche pas, et le dernier non 
> plus :-(

Quel est l'objectif?

[toc] | [prev] | [next] | [standalone]

#7744

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

> Thomas <fantome.forums.tDeContes@free.fr.invalid> wrote:
> > dans les 2 cas, chercher le 1er point ne marche pas, et le dernier non 
> > plus :-(
> 
> Quel est l'objectif?


je crois que j'ai trouvé comment résumer la situation :


depuis le début je parle depuis mon point de vue de développeur, mais 
Nicolas et toi ne l'aviez pas compris

Nicolas me suggérais par ex d'utiliser un "timestamp" à la seconde, 
plutôt qu'un "timestamp" au jour + un n° incrémental,
ce qui est tout à fait applicable depuis mon point de vue de développeur 
pour les fichiers de logs que mon logiciel gère lui même (voir qu. 3 du 
msg <fantome.forums.tDeContes-BC1C13.00324017072021@news.free.fr> )

alors j'envisageais d'ajouter ça juste avant le ".log", plutôt qu'après 
comme fait logrotate.


et puis j'ai eu l'idée de faire cette branche de la discussion :

> question sur les extensions, pour le cas où je généraliserais cette 
> procédure pour "pousser à coté" un fichier existant :

ça me permettrais d'appliquer cette procédure à tout type de fichier que 
mon logiciel aurais envie de créer, s'apercevant qu'un fichier de meme 
nom existe deja.


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

le pb est de pouvoir faire une telle procédure dans une bibliothèque, ce 
qui implique que cette procédure ne connaitra pas d'avance les 
extensions des fichiers qu'on va lui demander de "pousser à coté".

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

[toc] | [prev] | [next] | [standalone]

#7746

Thomas <fantome.forums.tDeContes@free.fr.invalid> wrote:
> le pb est de pouvoir faire une telle procédure dans une bibliothèque, ce 
> qui implique que cette procédure ne connaitra pas d'avance les 
> extensions des fichiers qu'on va lui demander de "pousser à coté".

Ce genre de chose, je préfère les mettre dans des scripts, que dans
l'application. C'est plus flexible.  Je ne comprends pas non plus cette
obsession pour les "extensions".  Un fichier est un fichier.

Mais à nouveau, mon point de vue est celui de l'intégrateur ou de
l'administrateur système.

Je crois que pour le moment je ne comprends pas l'objectif de
ton application.

[toc] | [prev] | [next] | [standalone]

#7751

In article <sd78cf$ktp$3@shakotay.alphanet.ch>,
 Marc SCHAEFER <schaefer@alphanet.ch> wrote:

> Thomas <fantome.forums.tDeContes@free.fr.invalid> wrote:
> > le pb est de pouvoir faire une telle procédure dans une bibliothèque, ce 
> > qui implique que cette procédure ne connaitra pas d'avance les 
> > extensions des fichiers qu'on va lui demander de "pousser à coté".
> 
> Ce genre de chose, je préfère les mettre dans des scripts, que dans
> l'application. C'est plus flexible.

ok

> Je ne comprends pas non plus cette
> obsession pour les "extensions".  Un fichier est un fichier.

de mon expérience, elles ont une certaine importance pour déterminer le 
type de contenu (comme dit dans le msg précédent dans le fil).

il me semble même qu'il y a des applications qui refusent d'ouvrir des 
fichiers qui n'ont pas l'extension attendue.


> 
> Mais à nouveau, mon point de vue est celui de l'intégrateur ou de
> l'administrateur système.

ok.
si tu n'es pas développeur, tu ne peux pas l'inventer ...
(l'es tu ?)


> 
> Je crois que pour le moment je ne comprends pas l'objectif de
> ton application.

(question connexe : quand dit on "application" et "logiciel" ?)


- logs :

(je pars de l'hypothèse où la réponse à la qu. 3 du msg 
<fantome.forums.tDeContes-BC1C13.00324017072021@news.free.fr> est "non")

pour éviter d'avoir des fichiers de log dont la taille va jusqu'à 
l'infini, il faut que je fasse de nouveaux fichiers de log de temps en 
temps.
ce qui me semble logique, c'est de le faire à chaque démarrage de 
l'application.

en tant qu'usager, ça m'embête que les anciens fichiers de log soient 
effacés à chaque fois, je préfère pouvoir les relire au cas où.


- fichier d'urgence :

cette application traite des fichiers .gui.
en cas d'erreur critique, elle tente de générer un fichier 
"emergency.gui", pour nous permettre de récupérer les modifications non 
enregistrées.
(le nom est codé en dur)

comme avec les logs, ça peut être pratique de pouvoir relire d'anciens 
fichiers "emergency.gui" quand il y en a plusieurs qui sont générés dans 
un délai restreint.


- code généré :

il y a peut être des cas où ça ne serait pas pertinent de sauver (plutôt 
que d'écraser) un fichier de code généré automatiquement,
mais ça peut l'être si la génération de code est partielle, et donc 
forcément destinée à être complétée à la main.

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

[toc] | [prev] | [next] | [standalone]

#7753

Thomas <fantome.forums.tDeContes@free.fr.invalid> wrote:
> si tu n'es pas développeur, tu ne peux pas l'inventer ...

Je développe ces temps principalement de l'embarqué en C (POSIX) et des
applications web en Perl, le tout sous Linux.

> (question connexe : quand dit on "application" et "logiciel" ?)

Pour moi c'est assez interchangeable: une application peut aussi être
vue comme plusieurs logiciels (style: frontend HTML5/CSS, backend Perl
et bash).
 
> pour éviter d'avoir des fichiers de log dont la taille va jusqu'à 
> l'infini, il faut que je fasse de nouveaux fichiers de log de temps en 
> temps.
> ce qui me semble logique, c'est de le faire à chaque démarrage de 
> l'application.

Oui, le wrapper en bash qui démarre ton application fait deux nouveaux
logs à partir de stderr et de stdin, sauf si le log est tellement petit
que cela vaut la peine de l'ajouter.

> en tant qu'usager, ça m'embête que les anciens fichiers de log soient 
> effacés à chaque fois, je préfère pouvoir les relire au cas où.

Ou alors conserver 2 versions, géré par le wrapper bash au lancement.

> comme avec les logs, ça peut être pratique de pouvoir relire d'anciens 
> fichiers "emergency.gui" quand il y en a plusieurs qui sont générés dans 
> un délai restreint.

La pratique de pas mal de logiciels, c'est 1 fichier de backup du passé;
si tu veux plus, tu peux configurer des rsync régulier de données sur
ton poste (`time machine').

Je trouverais affreux que ton application génère des backups de backups
de backups sans possibilité de configurer ça!  Mais par défaut, sans
configuration, 1 fichier de backup max peut convenir (appelé par exemple
.gui.backup vu que tu adores les extensions).

[toc] | [prev] | [next] | [standalone]

#7756

In article <sd8fk9$8ac$2@shakotay.alphanet.ch>,
 Marc SCHAEFER <schaefer@alphanet.ch> wrote:

> Thomas <fantome.forums.tDeContes@free.fr.invalid> wrote:
> > si tu n'es pas développeur, tu ne peux pas l'inventer ...
> 
> Je développe ces temps principalement de l'embarqué en C (POSIX) et des
> applications web en Perl, le tout sous Linux.

ok, je comprend un peu mieux pourquoi les extensions n'ont pas 
d'importance, et pourquoi il n'y a aucun pb à passer le fichier de 
config en ligne de commande :-)

quand on fait des applications graphiques, ce sont 2 choses qui ne sont 
pas aussi simple.

mais je viens de réaliser que, pour ce domaine précis, tout simplement 
je ne suis peut être pas sur le bon forum, pour trouver des gens un peu 
dans le même univers.
que me conseillerais tu ?
fr.comp.applications.x11 ? fr.comp.applications.libres ?
à chaque fois c'est un peu spécifique,
est ce qu'il y en a un qui serais suffisamment généraliste pour toutes 
les applications graphiques ? (hors applications web : je parle des 
applications installées sur son ordinateur et qui sont "à portée de 
clic")


> 
> > (question connexe : quand dit on "application" et "logiciel" ?)
> 
> Pour moi c'est assez interchangeable: une application peut aussi être
> vue comme plusieurs logiciels (style: frontend HTML5/CSS, backend Perl
> et bash).

ok

dans cette chose dont je suis le mainteneur, il y a principalement 2 
choses :
- une application cliquable,
- une bibliothèque, qui est utilisée par l'application cliquable ainsi 
que par toutes les applications qu'elle génère (et qui contient 
notamment l'accès au "toolkit" graphique - sauf que ça peut en être un 
autre que gtk).

je ne sais pas si c'est 1 logiciel constitué de ces 2 choses, ou 2 
logiciels,
et je pense qu'il y a une application, mais je ne sais pas si c'est 
l'application cliquable + la bibliothèque (qui permettent de compiler un 
exécutable cliquable), ou seulement le morceau "application cliquable".


>  
> > pour éviter d'avoir des fichiers de log dont la taille va jusqu'à 
> > l'infini, il faut que je fasse de nouveaux fichiers de log de temps en 
> > temps.
> > ce qui me semble logique, c'est de le faire à chaque démarrage de 
> > l'application.
> 
> Oui, le wrapper en bash qui démarre ton application fait deux nouveaux
> logs à partir de stderr et de stdin, sauf si le log est tellement petit
> que cela vaut la peine de l'ajouter.
> 
> > en tant qu'usager, ça m'embête que les anciens fichiers de log soient 
> > effacés à chaque fois, je préfère pouvoir les relire au cas où.
> 
> Ou alors conserver 2 versions, géré par le wrapper bash au lancement.

ça ne me dérange pas de préparer mon application pour faciliter la tache 
d'un intégrateur, mais dans mon idée c'est l'intégrateur qui ferais le 
wrapper, pas moi.

parallèlement à ça, j'aime mieux que des fichiers de log soient générés 
immédiatement, en plus de stdout et stderr,
autant pour moi, que pour un novice qui compilerais mon application à 
partir des sources, et à qui j'aurais besoin de demander qu'il m'envoie 
le log.

est ce que de ton point de vue, c'est à moi de faire le wrapper ?

> 
> > comme avec les logs, ça peut être pratique de pouvoir relire d'anciens 
> > fichiers "emergency.gui" quand il y en a plusieurs qui sont générés dans 
> > un délai restreint.
> 
> La pratique de pas mal de logiciels, c'est 1 fichier de backup du passé;
> si tu veux plus, tu peux configurer des rsync régulier de données sur
> ton poste (`time machine').
> 
> Je trouverais affreux que ton application génère des backups de backups
> de backups sans possibilité de configurer ça!  Mais par défaut, sans
> configuration, 1 fichier de backup max peut convenir

merci pour ton avis :-)

en regardant comment ça se passe dans /var/log/ ça m'a plu et ça m'a 
inspiré,
mais je ne savais pas que c'était géré par l'administration du système, 
et pas par chaque logiciel. c'était donc une mauvaise idée ...

> (appelé par exemple
> .gui.backup vu que tu adores les extensions).

ben non, justement, comme c'est ajouté à la fin ça casse l'extension ! 
si l'application y est trop sensible, ça obligera à modifier le nom du 
fichier pour pouvoir l'ouvrir à nouveau ...

y a t il une habitude, pour nommer les fichiers de backup ?

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

[toc] | [prev] | [next] | [standalone]

#7757

Thomas <fantome.forums.tDeContes@free.fr.invalid> wrote:
> quand on fait des applications graphiques, ce sont 2 choses qui ne sont 
> pas aussi simple.

Une application web n'est-elle pas une application graphique?

> que me conseillerais tu ?

Difficile à dire. Peut-être devrais-tu commencer à décrire exactement ce
que fait ton application.  Jusqu'ici on a compris que ça permettait
d'éditer des fichiers d'interfaces graphiques (IHM/GUI) et que ça
générait des logs.

> est ce qu'il y en a un qui serais suffisamment généraliste pour toutes 
> les applications graphiques ? (hors applications web : je parle des 
> applications installées sur son ordinateur et qui sont "à portée de 
> clic")

Je dois dire que je comprends de moins en moins la différence entre une
application localement installée et une application web: sur le mobile,
la différence entre application mobile native et application web
n'existe d'ailleurs plus, maintenant que les API HTML5 sont suffisamment
puissantes et qu'on peut déployer des Progressive Web Apps.

> - une application cliquable,
> - une bibliothèque, qui est utilisée par l'application cliquable ainsi 
> que par toutes les applications qu'elle génère (et qui contient 
> notamment l'accès au "toolkit" graphique - sauf que ça peut en être un 
> autre que gtk).

Toute application a toujours un core et une partie framework ou
bibliothèque où l'on regroupe les éléments essentiels.

> et je pense qu'il y a une application, mais je ne sais pas si c'est 
> l'application cliquable + la bibliothèque (qui permettent de compiler un 
> exécutable cliquable), ou seulement le morceau "application cliquable".

Ca n'a pas d'importance, à mon avis et avec les éléments qui me sont
connus.

> ça ne me dérange pas de préparer mon application pour faciliter la tache 
> d'un intégrateur, mais dans mon idée c'est l'intégrateur qui ferais le 
> wrapper, pas moi.

C'est tout à fait envisageable.
 
> parallèlement à ça, j'aime mieux que des fichiers de log soient générés 
> immédiatement, en plus de stdout et stderr,

Non, ceci serait de la duplication de travail par rapport à écrire un
simple wrapper shell du genre:

#! /bin/bash

. ~/.config-APPLICATION/defines

log_prefix=APPLICATION-
log_postfix=.log

# alternatives: pas de nom d'application dans le nom
# de fichier log, car implicite, pas de postfix
# car inutile, les fichiers d'erreur et d'info
# s'appellent alors ... error et info
log_prefix=
log_postfix=

# conserver une copie de chaque type de log
for i in info error
do
   [ -f $APPLICATION_LOG/$log_prefix{$i}$log_postfix ] \
      && mv -f $APPLICATION_LOG/$log_prefix{$i}$log_postfix \
               $APPLICATION_LOG/$log_prefix{$i}$log_postfix.1
done

exec $APPLICATION_BIN/application \
   2> $APPLICATION_LOG/${log_prefix}error$log_postfix
   > $APPLICATION_LOG/${log_prefix}info$log_postfix

Avec dans ~/.config-APPLICATION/defines

APPLICATION_PREFIX=<point d'installation, à adapter à l'installation>
APPLICATION_LOG=$APPLICATION_PREFIX/logs
APPLICATION_BIN=$APPLICATION_PREFIX/bin

> est ce que de ton point de vue, c'est à moi de faire le wrapper ?

Vu que tu viens d'exprimer le besoin de sauver des fichiers logs,
oui :)

> ben non, justement, comme c'est ajouté à la fin ça casse l'extension ! 

C'était exprès. En tant qu'utilisateur, je ne veux pas qu'il soit trop
facile de se tromper entre un original et une vieille copie.

Il faut choisir le bon backup, et le renommer pour y accéder, cela me
semble une excellente chose à faire pour éviter la confusion.

Ou, clic-droit, ouvrir avec ...

> si l'application y est trop sensible, ça obligera à modifier le nom du 
> fichier pour pouvoir l'ouvrir à nouveau ...
> 
> y a t il une habitude, pour nommer les fichiers de backup ?

Si ton application plante tellement souvent qu'il est une opération très
courante de devoir accéder aux backups et pas aux originaux, alors une
alternative est:

   fichier.gui -> fichier-backup.gui

mais c'est terriblement moche, je trouve, et on risque de confondre avec
l'original.

Après, je ne suis pas du tout un utilisateur Microsoft courant, donc je
ne pense certainement pas comme 95% des gens.

[toc] | [prev] | [next] | [standalone]

#7758

On 2021-07-22, Marc SCHAEFER <schaefer@alphanet.ch> wrote:
> Une application web n'est-elle pas une application graphique?

Non, c'est une application client/serveur. Le client (le browser web)
peut-être une application graphique (firefox, Chrome) ou pas (links,
lynx, w3m).

> Toute application a toujours un core et une partie framework ou
> bibliothèque où l'on regroupe les éléments essentiels.

Non plus, certaines applications sont faites ainsi, d'autres sont
purement monolithiques, d'autres fonctionnent selon d'autres logiques
ou méthodes.

>> parallèlement à ça, j'aime mieux que des fichiers de log soient générés 
>> immédiatement, en plus de stdout et stderr,

Le gros problème de la gestion des fichiers de logs est la rotation de
ces mêmes fichiers. Face à ce problème, il y a plusieurs solutions :

- Envoyer les logs sur STDERR (pas STDOUT qui n'est pas fait pour ça)
  et laisser l'admin ou le wrapper le gérer (avec logger par exemple).

- Gérer ses propres file descriptors, dans ce cas il faut gérer un
  signal pour fermer et ré-ouvrir les FD après rotation des logs

- S'en fiche (ce que font 99% des applications graphiques).

[toc] | [prev] | [next] | [standalone]

#7761

In article <sdcgo6$k10$1@gioia.aioe.org>,
 Stephane Tougard <stephane@unices.org> wrote:

> On 2021-07-22, Marc SCHAEFER <schaefer@alphanet.ch> wrote:
> > Une application web n'est-elle pas une application graphique?
> 
> Non, c'est une application client/serveur. Le client (le browser web)
> peut-être une application graphique (firefox, Chrome) ou pas (links,
> lynx, w3m).

merci, comme je n'y connais rien en mobile (entre autres) je ne savais 
pas du tout quoi répondre :-)


> >> parallèlement à ça, j'aime mieux que des fichiers de log soient générés 
> >> immédiatement, en plus de stdout et stderr,

est ce que ça te dirais de jeter un oeil à ce msg stp ?
<fantome.forums.tDeContes-BC1C13.00324017072021@news.free.fr>
si je l'ai bien compris, Marc répond "oui" aux 3 questions.

> 
> Le gros problème de la gestion des fichiers de logs est la rotation de
> ces mêmes fichiers.

- est ce que tu considères que l'application peut gérer un historique de 
fichiers de logs, comme logrotate,
- ou est ce que tu penses qu'il faut maximum 1 fichier de sauvegarde, 
comme Marc, mais gérer ce fichier de sauvegarde c'est déjà gérer de la 
rotation ?

> Face à ce problème, il y a plusieurs solutions :
> 
> - Envoyer les logs sur STDERR (pas STDOUT qui n'est pas fait pour ça)
>   et laisser l'admin ou le wrapper le gérer (avec logger par exemple).

du coup l'intégrateur met tous les logs dans le même fichier ? et c'est 
pas gênant ?
(et STDOUT est fait pour quoi ?)

> 
> - Gérer ses propres file descriptors, dans ce cas il faut gérer un
>   signal pour fermer et ré-ouvrir les FD après rotation des logs

peux tu préciser stp ?

comme j'ai déjà expliqué, pour la rotation je me contente de pousser les 
anciens fichiers au démarrage de l'application, comme ça :
- ça assure une rotation minimum,
- je n'ai pas besoin de gérer des choses en cours de route.

> 
> - S'en fiche (ce que font 99% des applications graphiques).

veux tu dire qu'elles produisent quand même des logs, mais qu'elles s'en 
fichent d'écraser les logs précédents ou d'en avoir qui montent jusqu'à 
l'infini ?

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

[toc] | [prev] | [next] | [standalone]

#7763

On 2021-07-23, Thomas <fantome.forums.tDeContes@free.fr.invalid> wrote:
> - est ce que tu considères que l'application peut gérer un historique de 
> fichiers de logs, comme logrotate,

Ça dépend de l'application et du besoin des logs.

> - ou est ce que tu penses qu'il faut maximum 1 fichier de sauvegarde, 
> comme Marc, mais gérer ce fichier de sauvegarde c'est déjà gérer de la 
> rotation ?

Non.

> du coup l'intégrateur met tous les logs dans le même fichier ? et c'est 
> pas gênant ?

L'intégrateur fait ce qu'il veut, ça n'a pas une grande importance.

> (et STDOUT est fait pour quoi ?)

C'est la sortie standard, c'est pour échanger avec l'applicatif (pour
une appli en ligne de commande). Sur une appli graphique, ça sert à rien.

> comme j'ai déjà expliqué, pour la rotation je me contente de pousser les 
> anciens fichiers au démarrage de l'application, comme ça :
> - ça assure une rotation minimum,
> - je n'ai pas besoin de gérer des choses en cours de route.

Encore une fois, ça dépend du type d'application et du besoin des logs.

>> - S'en fiche (ce que font 99% des applications graphiques).
>
> veux tu dire qu'elles produisent quand même des logs, mais qu'elles s'en 
> fichent d'écraser les logs précédents ou d'en avoir qui montent jusqu'à 
> l'infini ?

Lance un firefox en ligne de commande, tu vas t'apercevoir qu'il va
afficher plein de choses sur la console. Pour une utilisation
courante, on s'en fiche.

[toc] | [prev] | [next] | [standalone]

#7784

In article <sddfa6$15k4$1@gioia.aioe.org>,
 Stephane Tougard <stephane@unices.org> wrote:

> On 2021-07-23, Thomas <fantome.forums.tDeContes@free.fr.invalid> wrote:

> > du coup l'intégrateur met tous les logs dans le même fichier ? et c'est 
> > pas gênant ?
> 
> L'intégrateur fait ce qu'il veut,

pas tout à fait :
dans ce cas de figure, je ne crois pas qu'il ait la possibilité de 
re-separer le debug et les erreurs.

> ça n'a pas une grande importance.

en fait, quand j'ai fait les fichiers de logs, ça m'a paru naturel de 
faire un fichier pour chacun.
mais en fait, Marc et toi vous vous en fichez ?
un seul fichier avec tout ce qu'il y a à logger, ça vous va bien ?

> 
> > (et STDOUT est fait pour quoi ?)
> 
> C'est la sortie standard, c'est pour échanger avec l'applicatif (pour
> une appli en ligne de commande). Sur une appli graphique, ça sert à rien.

ok, donc tu as l'air d'accord avec Marc :-)


> >> - S'en fiche (ce que font 99% des applications graphiques).
> >
> > veux tu dire qu'elles produisent quand même des logs, mais qu'elles s'en 
> > fichent d'écraser les logs précédents ou d'en avoir qui montent jusqu'à 
> > l'infini ?
> 
> Lance un firefox en ligne de commande, tu vas t'apercevoir qu'il va
> afficher plein de choses sur la console. Pour une utilisation
> courante, on s'en fiche.

il y a un module qui envoie automatiquement un rapport en cas de crash.

si j'ai bien compris, il récupère via un wrapper script ce qu'on voit 
sur la console,
simplement, quand on le lance en ligne de commande, cette redirection 
n'est pas faite ?

est ce que ce module a du être programmé séparément pour chaque 
plateforme ?

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

[toc] | [prev] | [next] | [standalone]

#7765

Thomas <fantome.forums.tDeContes@free.fr.invalid> wrote:
>> On 2021-07-22, Marc SCHAEFER <schaefer@alphanet.ch> wrote:
>> > Une application web n'est-elle pas une application graphique?
>> 
>> Non, c'est une application client/serveur. Le client (le browser web)
>> peut-être une application graphique (firefox, Chrome) ou pas (links,
>> lynx, w3m).
> 
> merci, comme je n'y connais rien en mobile (entre autres) je ne savais 
> pas du tout quoi répondre :-)

J'ai aussi conçu des applications desktop client/serveur.

D'autant plus que les applications web modernes ne font souvent que
chercher des données en web pour les affichers grâce au javascript
local, ce qui ressemble beaucoup à une application desktop qui se
connecte à une base de données.

Pour clarifier la discussion, posons:

   - application bureau (desktop) monolithique

        pas d'usage du réseau, d'une base de données réseau,
        etc

   - application bureau client/serveur

       utilisation d'une base de données SQL ou autre, y.c.
       données sur le web (REST/HTTP)

   - application web classique client/serveur

       présentation par le serveur, mise en forme par le client
       (peu/pas de javascript)

   - application web moderne client/serveur

       très similaire à "application bureau client/serveur"

   - application mobile native

       très similaire à "application bureau client/serveur"

   - application mobile Progressive Web App

       très similaire à "application mobile native" sauf que
       100% HTML/CSS/JS

Et il y a des variations, des combinaisons, etc.

Il ne me semblait pas que le fait que l'application soit bureau ou non
change grand chose: il faut des configs quelque part (locale ou
distante, possible aussi pour une application bureau client/serveur).

> c'est pas gênant ?  (et STDOUT est fait pour quoi ?)

Pour une application qui ne communique en fait pas avec l'utilisateur en
console, on peut définir stdout comme les notifications normales et
stderr comme les erreurs.

Pour une application qui communique avec l'utilisateur en console (pas
ton cas me semble-t-il), stdin/stdout est pour l'interaction
utilisateur, stderr pour les erreurs.

[toc] | [prev] | [next] | [standalone]

#7778

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

> Thomas <fantome.forums.tDeContes@free.fr.invalid> wrote:
> >> On 2021-07-22, Marc SCHAEFER <schaefer@alphanet.ch> wrote:
> >> > Une application web n'est-elle pas une application graphique?
> >> 
> >> Non, c'est une application client/serveur. Le client (le browser web)
> >> peut-être une application graphique (firefox, Chrome) ou pas (links,
> >> lynx, w3m).
> > 
> > merci, comme je n'y connais rien en mobile (entre autres) je ne savais 
> > pas du tout quoi répondre :-)
> 
> J'ai aussi conçu des applications desktop client/serveur.
> 
> D'autant plus que les applications web modernes ne font souvent que
> chercher des données en web pour les affichers grâce au javascript
> local, ce qui ressemble beaucoup à une application desktop qui se
> connecte à une base de données.

dis moi si je me trompe : il me semble qu'il reste une /grosse/ 
différence :
- une application desktop est un exécutable compilé pour la plateforme 
qui l'exécute,
- une application web est interprétée par un navigateur.
avec des avantages et des inconvénients de chaque coté

> 
> Pour clarifier la discussion, posons:
> 
>    - application bureau (desktop) monolithique
> 
>         pas d'usage du réseau, d'une base de données réseau,
>         etc
> 
>    - application bureau client/serveur
> 
>        utilisation d'une base de données SQL ou autre, y.c.
>        données sur le web (REST/HTTP)
> 
>    - application web classique client/serveur
> 
>        présentation par le serveur, mise en forme par le client
>        (peu/pas de javascript)
> 
>    - application web moderne client/serveur
> 
>        très similaire à "application bureau client/serveur"
> 
>    - application mobile native
> 
>        très similaire à "application bureau client/serveur"
> 
>    - application mobile Progressive Web App
> 
>        très similaire à "application mobile native" sauf que
>        100% HTML/CSS/JS

pour l'instant, celle que je fais semble être :
une "application bureau monolithique"
(d'après ta description, parce que d'après ce que dis Stephane c'est pas 
sur, puisqu'il y a une bibliothèque. je ne saisis pas encore bien toutes 
les nuances)

pour ma part, je me vois faire :
- application bureau client/serveur
- (peut être) application web classique client/serveur

pour l'instant c'est tout, et c'est encore du futur ...


> Il ne me semblait pas que le fait que l'application soit bureau ou non
> change grand chose: il faut des configs quelque part (locale ou
> distante, possible aussi pour une application bureau client/serveur).

il me semble qu'il y a des contraintes diverses, non ?

par exemple, peut on passer un argument à une application web pour 
qu'elle lise un fichier de config local ?
clairement, les logs sont gérés directement par le serveur,
les potentielles mauvaises pratiques n'affectent pas l'usager, à qui on 
n'a pas besoin de demander d'envoyer ses fichiers de logs pour 
comprendre le pb.

tandis qu'avec une application bureau client/serveur, il y a une part de 
chaque coté, le serveur ne gère pas tout.




> 
> > c'est pas gênant ?  (et STDOUT est fait pour quoi ?)
> 
> Pour une application qui ne communique en fait pas avec l'utilisateur en
> console, on peut définir stdout comme les notifications normales et
> stderr comme les erreurs.

est ce que le debug équivaut à des "notifications normales", ou est ce 
que c'est autre chose ?

> 
> Pour une application qui communique avec l'utilisateur en console (pas
> ton cas me semble-t-il),

en fait, le "gros morceau" est une application graphique, mais :
- le même exécutable peut aussi être utilisé en CLI à la place
- d'autres exécutables, qui servent aux tests, font les 2 en même temps

comment me conseilles tu de gérer ça ?

> stdin/stdout est pour l'interaction
> utilisateur, stderr pour les erreurs.

quand il y a des msgs du genre "ignoring unknown switch" ou "Interactive 
mode permits only one file on the command line",
comment les catégorises tu ? interaction utilisateur ou erreurs ?

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

[toc] | [prev] | [next] | [standalone]

#7783

Thomas <fantome.forums.tDeContes@free.fr.invalid> wrote:
> - une application desktop est un exécutable compilé pour la plateforme 
> qui l'exécute,

correct, sauf si c'est du bytecode ou du script (python, perl), là il
n'y a pas de phase de compilation.

> par exemple, peut on passer un argument à une application web pour 
> qu'elle lise un fichier de config local ?

Non, bien sûr, il y a des différences.

> tandis qu'avec une application bureau client/serveur, il y a une part de 
> chaque coté, le serveur ne gère pas tout.

Et le client peut envoyer ses logs au serveur, ou pas.

> est ce que le debug équivaut à des "notifications normales", ou est ce 
> que c'est autre chose ?

Ah, le debug je l'activerais optionnellement et à part.

stdout: informations normales (version du programme, opérations
normales)

stderr: erreurs, évt. debug.

> quand il y a des msgs du genre "ignoring unknown switch" ou "Interactive 
> mode permits only one file on the command line",
> comment les catégorises tu ? interaction utilisateur ou erreurs ?

erreurs.

On doit pouvoir faire

   ton-programme 2>/dev/null

et n'avoir que des informations et aucun message d'erreur.

[toc] | [prev] | [next] | [standalone]

#7789

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

> Thomas <fantome.forums.tDeContes@free.fr.invalid> wrote:
> > - une application desktop est un exécutable compilé pour la plateforme 
> > qui l'exécute,
> 
> correct, sauf si c'est du bytecode ou du script (python, perl), là il
> n'y a pas de phase de compilation.

le bytecode c'est le truc qu'on fait interpréter par les JVM ?
(dans ce cas là il y a un peu de compilation quand même, puisque c'est 
du code intermédiaire)


> > tandis qu'avec une application bureau client/serveur, il y a une part de 
> > chaque coté, le serveur ne gère pas tout.
> 
> Et le client peut envoyer ses logs au serveur, ou pas.

:-)

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 !

d'où la question que j'ai posée à Stephane Tougard sur firefox :-)



> 
> > est ce que le debug équivaut à des "notifications normales", ou est ce 
> > que c'est autre chose ?
> 
> 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" ?)

> 
> stdout: informations normales (version du programme, opérations
> normales)
> 
> stderr: erreurs, évt. debug.

merci :-)

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

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 ?

> 
> > quand il y a des msgs du genre "ignoring unknown switch" ou "Interactive 
> > mode permits only one file on the command line",
> > comment les catégorises tu ? interaction utilisateur ou erreurs ?
> 
> erreurs.

ok :-)

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

> 
> On doit pouvoir faire
> 
>    ton-programme 2>/dev/null
> 
> et n'avoir que des informations et aucun message d'erreur.

par rapport à la question ci-dessus,
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 ?

(un peu plus fastidieux que si on traite tout pareil !)

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

[toc] | [prev] | [next] | [standalone]

#7791

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)

Il y a toutefois des cas où l'on transcompile le bytecode en code natif
(just in time), typiquement sur Android au moment où on installe
l'application.

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

Typiquement, sous UNIX, il m'est arrivé de configurer des applications
de manière à ce que le le log aille dans:

   /network/fs.toto.ch/logs/$CLIENT/application-${UNIQUE}.log

et par la magie de l'automounter, les logs finissent sur le serveur
fs.toto.ch, dans le répertoire correspondant au nom du client, dans un
fichier correspondant au nom de l'application suffixée d'une valeur
unique contenant la date.

Evidemment, ça marche uniquement dans un réseau intégré ("domaine").

Autre technique que j'ai utilisée: quand le programme se termine, le log
est pushé sur le serveur par HTTPS.

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

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

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

> 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é. Je me demande si plutôt qu'une discussion
USENET tu ne devrais pas créer un wiki pour organiser tes pensées et les
réponses qui te sont données, et qui nous permettrait de nous rappeler
ce qu'on a déjà discuté :)

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

J'ai tendance à faire ainsi en shell:

if [ mauvais arguments donnés ]; then
   echo "$0: bad args." >&2
   echo "$0 [--config toto.conf]" >&2
fi

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.

(Pour rappel, >&2 signifie écrire dans stderr).

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

[toc] | [prev] | [next] | [standalone]

Page 3 of 5 — ← Prev page 1 2 [3] 4 5  Next page →

Back to top | Article view | fr.comp.os.unix

csiph-web