Path: ...!weretis.net!feeder6.news.weretis.net!feeder8.news.weretis.net!2.eu.feeder.erje.net!feeder.erje.net!news.alphanet.ch!alphanet.ch!.POSTED.localhost!not-for-mail From: Marc SCHAEFER Newsgroups: fr.comp.os.unix Subject: Re: =?ISO-8859-1?Q?g=E9rer?= des fichiers log Date: Fri, 24 Sep 2021 17:36:44 -0000 (UTC) Organization: Posted through ALPHANET (https://news.alphanet.ch/) Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Injection-Date: Fri, 24 Sep 2021 17:36:44 -0000 (UTC) Injection-Info: shakotay.alphanet.ch; posting-host="localhost:127.0.0.1"; logging-data="11008"; mail-complaints-to="usenet@alphanet.ch" User-Agent: tin/2.4.3-20181224 ("Glen Mhor") (UNIX) (Linux/4.19.0-17-amd64 (x86_64)) Cancel-Lock: sha256:lvVi/qIRuQ+RYKdXIEeoE+fwOE8suwh/zZ0zfZd3Av8= Bytes: 4580 Lines: 83 Thomas 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?