Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > fr.comp.os.unix > #7714 > unrolled thread
| Started by | Thomas <fantome.forums.tDeContes@free.fr.invalid> |
|---|---|
| First post | 2021-07-05 21:41 +0200 |
| Last post | 2022-07-30 16:42 +0200 |
| Articles | 20 on this page of 86 — 7 participants |
Back to article view | Back to fr.comp.os.unix
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 2 of 5 — ← Prev page 1 [2] 3 4 5 Next page →
| From | Marc SCHAEFER <schaefer@alphanet.ch> |
|---|---|
| Date | 2021-07-21 06:36 +0000 |
| Message-ID | <sd8faa$8ac$1@shakotay.alphanet.ch> |
| In reply to | #7748 |
Thomas <fantome.forums.tDeContes@free.fr.invalid> wrote: > tu as dit "le répertoire courant du lancement du logiciel", > si je comprend bien, ça veut dire qu'il faut enregistrer l'emplacement > du répertoire courant au démarrage, au cas où le logiciel décide d'en > changer ensuite. (ai je bien compris ?) oui. Alternative: le fichier de config spécifié en ligne de commande (ou dans ~/.nom-application) indique où se trouve > en tant qu'usager, ça m'embête d'avoir à faire attention au répertoire > courant au motif que le logiciel va mettre des choses à lui dedans > (est ce une pratique courante ?), pas du tout, la pratique c'est un fichier de configuration :) > en fait, quand un logiciel a des "affaires à lui" à mettre qqpart, la > pratique ça serais pas plutôt qqch du genre "~/.config/<logiciel>/" ? oui, aussi, mais en ce qui me concerne j'aime que cela soit configurable. > peut il y avoir un intérêt à faire ça ? à changer de répertoire courant? non, c'est un choix de l'utilisateur, cela ne devrait pas être un choix de ton application. > risqué : > peux tu préciser un peu stp ? Je peux lancer ton logiciel comme toto/bla tu te lances comme bla tu dois alors faire: répertoire courant + "toto" pour avoir le répertoire courant de l'application. Mais voici ce que je peux faire sous UNIX (dans /tmp/tt pour la démo): Supposons que ton application s'appelle /tmp/tt/bin/bla (j'ai fait un simple cp /bin/cat /tmp/tt/bin/bla pour la démo): terminal 1: # je lance ton programme schaefer@reliand:/tmp/tt$ bin/bla terminal 2: # pendant l'exécution, je change la structure des répertoires schaefer@reliand:/tmp/tt$ mv bin toto Suivant à quel moment ton programme va faire répertoire courant + "bin" pour avoir le répertoire de l'application, ça ne marchera plus. Et si tu as changé ton répertoire courant (pourquoi?), alors cela ne marchera jamais. C'est autorisé sous UNIX (pas la notion de `répertoire utilisé' comme sous Microsoft). Je ne dis pas qu'on va faire ça tous les jours, mais les bonnes pratiques UNIX consistent à ne pas essayer de découvrir ce genre de chose et à utiliser des fichiers de configurations statiques dans ~/.config ou dont les noms sont passés en ligne de commande. Bon, dans ce cas, la manière sûre, sous Linux, d'obtenir le répertoire de l'application est via /proc/self/exe (mais ce n'est pas portable). > est ce que c'est une mauvaise conception ? Je ne sais pas, je ne sais toujours pas pourquoi ton programme a besoin de créer des fichiers de logs plutôt que d'utiliser stdout et stderr, et je ne sais pas pourquoi il a besoin d'extensions de fichiers, ni pourquoi il désire changer de répertoire courant :)
[toc] | [prev] | [next] | [standalone]
| From | Thomas <fantome.forums.tDeContes@free.fr.invalid> |
|---|---|
| Date | 2021-07-23 01:58 +0200 |
| Message-ID | <fantome.forums.tDeContes-433B13.01575723072021@news.free.fr> |
| In reply to | #7752 |
In article <sd8faa$8ac$1@shakotay.alphanet.ch>, Marc SCHAEFER <schaefer@alphanet.ch> wrote: > Thomas <fantome.forums.tDeContes@free.fr.invalid> wrote: > > tu as dit "le répertoire courant du lancement du logiciel", > > si je comprend bien, ça veut dire qu'il faut enregistrer l'emplacement > > du répertoire courant au démarrage, au cas où le logiciel décide d'en > > changer ensuite. (ai je bien compris ?) > > oui. est ce que tu prends en considération cette possibilité malgré le fait de trouver ça saugrenu ? (parce que comme t'as dit ça, ça m'a un peu perturbé, du coup) (voir ci dessous) > > Alternative: le fichier de config spécifié en ligne de commande (ou dans > ~/.nom-application) indique où se trouve ~/.<nom-application>/ plutôt que ~/.config/<nom-application>/ ? perso, je n'aime pas me retrouver avec une quantité astronomique de ~/.* :-( j'aimerais bcp mieux que tout ça soit rangé dans un répertoire, mais pour ça il faut que bcp de développeurs se mettent d'accord ..... ! (`~/.config/` ? `~/.hidden-data/` ?) > > > en tant qu'usager, ça m'embête d'avoir à faire attention au répertoire > > courant au motif que le logiciel va mettre des choses à lui dedans > > (est ce une pratique courante ?), > > pas du tout, la pratique c'est un fichier de configuration :) ok :-) je ne te promet absolument rien. mais au cas où ... aurais tu des tuyaux à me donner, pour lire un fichier de configuration d'une manière qui soit à la fois suffisamment fiable et pas trop casse-pied à programmer ? > > > en fait, quand un logiciel a des "affaires à lui" à mettre qqpart, la > > pratique ça serais pas plutôt qqch du genre "~/.config/<logiciel>/" ? > > oui, aussi, mais en ce qui me concerne j'aime que cela soit > configurable. tu veux dire que tu trouves acceptable que ça soit le comportement par défaut, mais que tu veux pouvoir le modifier par la ligne de commande, c'est ça ? (parce que si je dois chercher un fichier de configuration, je l'aurais cherché là aussi) > > > peut il y avoir un intérêt à faire ça ? > > à changer de répertoire courant? oui > non, c'est un choix de l'utilisateur, > cela ne devrait pas être un choix de ton application. en fait, a priori j'étais comme toi, je trouvais ça saugrenu qu'un logiciel autre qu'un shell modifie son répertoire courant (et je me demande pourquoi l'API Ada nous donne cette possibilité) mais en fait il y a 2 façons de voir les choses : quand une application graphique affiche une boite de dialogue avec l'arborescence du disque, pour nous demander de choisir un fichier : - soit on considère que c'est équivalent à une application CLI à qui on passe le nom du fichier comme argument, avec un chemin - soit on considère que c'est équivalent à un shell dans lequel on fait des `cd`, et à la fin on passe le nom du fichier comme argument, sans chemin je crois que toi et moi on est tous les 2 sur la 1ere alternative, mais je devine que le mainteneur précédent (ou le précédent encore) qui a programmé ça était sur la 2eme :-) un avis là dessus ? si une application graphique ne devrais /jamais/ changer de répertoire courant, - est ce que c'est un domaine strictement réservé aux shells, - ou est ce qu'il y a d'autres cas de figure où c'est approprié qu'un logiciel le fasse ? > > > risqué : > > peux tu préciser un peu stp ? > Mais voici ce que je peux faire sous UNIX > terminal 1: > # je lance ton programme > schaefer@reliand:/tmp/tt$ bin/bla > > terminal 2: > # pendant l'exécution, je change la structure des répertoires > schaefer@reliand:/tmp/tt$ mv bin toto > > Suivant à quel moment ton programme va faire répertoire courant + "bin" > pour avoir le répertoire de l'application, ça ne marchera plus. > C'est autorisé sous UNIX disons que, quelle que soit la méthode utilisée par l'application pour définir un chemin dont elle aura besoin au cours de sa vie, changer la structure des répertoires pendant qu'elle tourne est risqué : j'ai entendu dire que la pratique est de lire le fichier de config au démarrage, mais pas de vérifier régulièrement s'il a été modifié. > > Je ne dis pas qu'on va faire ça tous les jours, mais les bonnes > pratiques UNIX consistent à ne pas essayer de découvrir ce genre de > chose et à utiliser des fichiers de configurations statiques dans > ~/.config ou dont les noms sont passés en ligne de commande. ok, je tache de le retenir :-) > > est ce que c'est une mauvaise conception ? > > Je ne sais pas, je ne sais toujours pas pourquoi ton programme a besoin > de créer des fichiers de logs plutôt que d'utiliser stdout et stderr, en plus, pas à la place. c'est pour ça qu'il est imaginable d'ignorer les erreurs d'écriture quand il y en a, considérant que c'est rattrapable via stdout et stderr (mais en fait c'est ce que j'avais écrit juste avant, non ?) mais je viens de voir qu'il y a une suite de l'autre coté, avec un nouvel intervenant :-) > et > je ne sais pas pourquoi il a besoin d'extensions de fichiers, j'espérais l'avoir déjà expliqué suffisamment, avec mon exemple d'éditeur de texte : <fantome.forums.tDeContes-7F6309.18430417072021@news.free.fr> (et TextWrangler est très souple, il ne s'en sert que pour colorer les mots clés et des comportements dans ce genre) > ni > pourquoi il désire changer de répertoire courant :) voir ci dessus, j'espère que c'est suffisamment clair :-) -- RAPID maintainer http://savannah.nongnu.org/projects/rapid/
[toc] | [prev] | [next] | [standalone]
| From | Marc SCHAEFER <schaefer@alphanet.ch> |
|---|---|
| Date | 2021-07-23 06:41 +0000 |
| Message-ID | <sddoan$flh$1@shakotay.alphanet.ch> |
| In reply to | #7759 |
Thomas <fantome.forums.tDeContes@free.fr.invalid> wrote:
> est ce que tu prends en considération cette possibilité malgré le fait
> de trouver ça saugrenu ?
Si tu changes le répertoire courant (ce que je trouve, sans autre
explication, saugrenu), alors tu dois mémoriser où c'était.
mais ça pose d'autres problèmes, suivant comment tu le mémorises:
- si tu le mémorises sous forme d'un handle de répertoire ouvert,
parfait
- si tu le mémorises sous forme de chemin, alors tu as le même
risque si quelqu'un modifie l'arborescence
Ce problème ne se pose pas si on ne change pas le répertoire courant.
Et si tu génères uniquement des logs dans stdout et stderr, le besoin du
répertoire courant est inutile, sauf si tu charges des fichiers
relativement à lui (ce qui me semble une bonne pratique), mais alors il
n'y a rien à faire: juste ouvrir les fichiers (config p.ex.) avec le
chemin indiqué par l'utilisateur (relatif ou absolu).
Par contre, si tu changes le répertoire courant, tu ne peux plus ouvrir
les fichiers dont le chemin indiqué est relatif sans y concaténer le
répertoire courant sauvegardé, avec les bugs ci-dessus.
Donc KISS: ne pas changer le répertoire courant.
> ~/.<nom-application>/
> plutôt que
> ~/.config/<nom-application>/
Les deux existent, le ~/.config est une convention plutôt récente des
GUI comme GNOME ou kde, me semble-t-il. Mais le mieux est de consulter
le Filesystem Hierarchy Standard (même s'il devient apparemment
obsolète).
> perso, je n'aime pas me retrouver avec une quantité astronomique de ~/.*
> :-(
Ca ne gêne pas sous UNIX, ce sont des fichiers cachés et la performance
du fs est bonne jusqu'à quelques milliers de fichiers.
> j'aimerais bcp mieux que tout ça soit rangé dans un répertoire, mais
> pour ça il faut que bcp de développeurs se mettent d'accord ..... !
>
> (`~/.config/` ? `~/.hidden-data/` ?)
Alternative: ne pas imposer ce choix à l'utilisateur, mais passer le nom
du fichier de config en argument, éventuellement avec une
préconfiguration classique dans le wrapper.
> aurais tu des tuyaux à me donner, pour lire un fichier de configuration
> d'une manière qui soit à la fois suffisamment fiable et pas trop
> casse-pied à programmer ?
cle1=valeur1\n
cle2=valeur2\n
avantage: sourceable en wrapper bash.
Sinon, il y a des milliers de formats en fonction des besoins.
> tu veux dire que tu trouves acceptable que ça soit le comportement par
> défaut, mais que tu veux pouvoir le modifier par la ligne de commande,
> c'est ça ?
oui, ou le fichier de config *doit* être spécifié systématiquement en
ligne de commande; les deux me vont car dans le 2e cas ... on peut faire
un wrapper pour réduire au 1er cas.
> en fait, a priori j'étais comme toi, je trouvais ça saugrenu qu'un
> logiciel autre qu'un shell modifie son répertoire courant (et je me
> demande pourquoi l'API Ada nous donne cette possibilité)
sémantiquement, tu vas changer de répertoire à chaque fois que tu veux
relativement exprimer un chemin depuis ce répertoire, mais il faut faire
attention à bien faire ce que l'utilisateur s'attend.
Si l'utilisateur tape:
bin/ton-programme configs/simple-config
alors il s'attend que le chemin configs/simple-config soit exprimé
relativement au répertoire courant au moment de lancer ta commande; si
tu changes le répertoire courant puis ensuite accède le fichier de
configuration, cela ne sera pas le bon chemin!
Autre exemple confusionnant: les anciennes versions de libreoffice,
quand tu les démarrais avec répertoire courant ~/toto sauvaient
quand même dans ~ -- les nouvelles sont mieux faites (le répertoire
courant du lancement initial figure maintenant dans la boîte de dialogue
de sauvegarde, c'est déjà mieux que rien).
> l'arborescence du disque, pour nous demander de choisir un fichier :
L'arborescence du système de fichiers (un disque contient des partitions
qui contiennent un système de fichier qui peut être monté où tu veux
sous UNIX).
> - soit on considère que c'est équivalent à une application CLI à qui on
> passe le nom du fichier comme argument, avec un chemin
> - soit on considère que c'est équivalent à un shell dans lequel on fait
> des `cd`, et à la fin on passe le nom du fichier comme argument, sans
> chemin
>
> je crois que toi et moi on est tous les 2 sur la 1ere alternative,
> mais je devine que le mainteneur précédent (ou le précédent encore) qui
> a programmé ça était sur la 2eme :-)
>
> un avis là dessus ?
Il me semblerait logique que le répertoire courant dans lequel on a
démarré l'application (en shell ou en GUI) soit le premier présenté par
la boîte de sélection, et ensuite il me semblerait logique que la boîte
de sélection retourne le chemin relatif depuis ce répertoire courant du
fichier sélectionné, ou le chemin absolu si la personne a choisi
d'entrer un chemin absolu ou a cliqué sur autre chose que le répertoire
courant.
> si une application graphique ne devrais /jamais/ changer de répertoire
> courant,
> - est ce que c'est un domaine strictement réservé aux shells,
> - ou est ce qu'il y a d'autres cas de figure où c'est approprié qu'un
> logiciel le fasse ?
Je pense qu'une application quelconque a plein de raison de changer de
répertoire courant (p.ex. lancer un logiciel complémentaire dans son
environnement propre), mais elle peut sauvegarder le répertoire
précédent et y revenir (sous forme de handler c'est mieux que sous forme
de chemin absolu, comme déjà mentionné).
> disons que, quelle que soit la méthode utilisée par l'application pour
> définir un chemin dont elle aura besoin au cours de sa vie, changer la
> structure des répertoires pendant qu'elle tourne est risqué :
> j'ai entendu dire que la pratique est de lire le fichier de config au
> démarrage, mais pas de vérifier régulièrement s'il a été modifié.
C'est juste: il ne faudrait changer aucun des chemins absolus qui
figureraient dans la config. Par contre, si tout est exprimé
relativement au répertoire courant, le risque n'existe pas.
>> Je ne sais pas, je ne sais toujours pas pourquoi ton programme a besoin
>> de créer des fichiers de logs plutôt que d'utiliser stdout et stderr,
>
> en plus, pas à la place.
Ah, des logs supplémentaires? Pourquoi? Comment? Combien?
> c'est pour ça qu'il est imaginable d'ignorer les erreurs d'écriture
> quand il y en a, considérant que c'est rattrapable via stdout et stderr
> (mais en fait c'est ce que j'avais écrit juste avant, non ?)
Je ne comprends pas ce que tu entends par erreur d'écriture et en
particulier avec stdout et stderr.
[toc] | [prev] | [next] | [standalone]
| From | Thomas <fantome.forums.tDeContes@free.fr.invalid> |
|---|---|
| Date | 2021-09-19 19:23 +0200 |
| Message-ID | <fantome.forums.tDeContes-5442BA.19235419092021@news.free.fr> |
| In reply to | #7764 |
In article <sddoan$flh$1@shakotay.alphanet.ch>, Marc SCHAEFER <schaefer@alphanet.ch> wrote: > - si tu le mémorises sous forme d'un handle de répertoire ouvert, > parfait je n'ai pas entendu dire qu'on pouvait faire ça en ada, ça doit être une fonction spécifique UNIX ? > > - si tu le mémorises sous forme de chemin, alors tu as le même > risque si quelqu'un modifie l'arborescence > > Ce problème ne se pose pas si on ne change pas le répertoire courant. > > Et si tu génères uniquement des logs dans stdout et stderr, le besoin du > répertoire courant est inutile, sauf si tu charges des fichiers > relativement à lui (ce qui me semble une bonne pratique), mais alors il > n'y a rien à faire: juste ouvrir les fichiers (config p.ex.) avec le > chemin indiqué par l'utilisateur (relatif ou absolu). si je te comprend bien, l'avantage de se référer au répertoire courant, sans le mémoriser ni le changer, c'est qu'il supporte les renommages en cours d'exécution ? et si on supprime ce répertoire, qu'est ce que ça donne ? (sujet connexe) bon, a priori, je n'ai pas besoin de pousser la résilience de mon logiciel au point où on puisse le changer de place pendant son exécution, ça me parait raisonnable de demander à l'utilisateur de le fermer pour faire ça. (je comprend tout à fait que ça puisse être un besoin pour les serveurs, par exemple) > Donc KISS: ne pas changer le répertoire courant. j'étais de ton avis donc tu n'as pas tellement eu à me convaincre, donc je vais virer tout ça et gérer les chemins autrement :-) > > > ~/.<nom-application>/ > > plutôt que > > ~/.config/<nom-application>/ > > Les deux existent, le ~/.config est une convention plutôt récente des > GUI comme GNOME ou kde, me semble-t-il. ah, tant mieux ! alors j'invite tous les developpeurs qui me lisent à préférer ~/.config/<nom-application>/ pour ranger leurs données :-) > Mais le mieux est de consulter > le Filesystem Hierarchy Standard (même s'il devient apparemment > obsolète). qu'est ce que c'est ? (il a peut être besoin d'une mise à jour ?) > > > perso, je n'aime pas me retrouver avec une quantité astronomique de ~/.* > > :-( > > Ca ne gêne pas sous UNIX, ce sont des fichiers cachés "tant mieux" pour la vie de tous les jours, sauf que de temps en temps on a besoin de les afficher quand même, autant en interface graphique qu'en ligne de commande. et là le rangement en sous-répertoires retrouve tout son intérêt pour la commodité. > > j'aimerais bcp mieux que tout ça soit rangé dans un répertoire, mais > > pour ça il faut que bcp de développeurs se mettent d'accord ..... ! > > > > (`~/.config/` ? `~/.hidden-data/` ?) > > Alternative: ne pas imposer ce choix à l'utilisateur, mais passer le nom > du fichier de config en argument, éventuellement avec une > préconfiguration classique dans le wrapper. (voir plus bas) > > aurais tu des tuyaux à me donner, pour lire un fichier de configuration > > d'une manière qui soit à la fois suffisamment fiable et pas trop > > casse-pied à programmer ? en fait, je pense que j'aurai l'occasion de faire une fenêtre de "préférences", qui va éditer "en mode graphique" un fichier de ce genre (donc ce fichier sera écrit et lu symétriquement, et pas édité à la main). Par contre, ça ne résout pas le pb de la localisation de ce fichier ... > > tu veux dire que tu trouves acceptable que ça soit le comportement par > > défaut, mais que tu veux pouvoir le modifier par la ligne de commande, > > c'est ça ? > > oui, ou le fichier de config *doit* être spécifié systématiquement en > ligne de commande; les deux me vont car dans le 2e cas ... on peut faire > un wrapper pour réduire au 1er cas. j'ai cru comprendre que pour permettre aux utilisateurs de Windows de double cliquer sur un fichier pour l'ouvrir, il est nécessaire de prendre en charge l'indication du fichier cliqué comme argument unique (je ne sais pas comment ça se passe sur les autres plateformes) donc, comment faire qqch qui réponde à ton besoin et qui soit compatible avec ce comportement de Windows ? (en essayant d'éviter des galipettes du genre : lire le fichier pour savoir si c'est un fichier de config ou un document utilisateur) (voir l'autre branche du fil) > > > en fait, a priori j'étais comme toi, je trouvais ça saugrenu qu'un > > logiciel autre qu'un shell modifie son répertoire courant (et je me > > demande pourquoi l'API Ada nous donne cette possibilité) > > sémantiquement, tu vas changer de répertoire à chaque fois que tu veux > relativement exprimer un chemin depuis ce répertoire, mais il faut faire > attention à bien faire ce que l'utilisateur s'attend. dans quels cas on peut vouloir exprimer un chemin relativement depuis un autre répertoire ? (voir plus bas) > > - soit on considère que c'est équivalent à une application CLI à qui on > > passe le nom du fichier comme argument, avec un chemin > > - soit on considère que c'est équivalent à un shell dans lequel on fait > > des `cd`, et à la fin on passe le nom du fichier comme argument, sans > > chemin > > > > je crois que toi et moi on est tous les 2 sur la 1ere alternative, > > mais je devine que le mainteneur précédent (ou le précédent encore) qui > > a programmé ça était sur la 2eme :-) > > > > un avis là dessus ? > > Il me semblerait logique que le répertoire courant dans lequel on a > démarré l'application (en shell ou en GUI) soit le premier présenté par > la boîte de sélection, et ensuite il me semblerait logique que la boîte > de sélection retourne le chemin relatif depuis ce répertoire courant du > fichier sélectionné, ou le chemin absolu si la personne a choisi > d'entrer un chemin absolu ou a cliqué sur autre chose que le répertoire > courant. ok, quand on change de répertoire, on bascule en "tout en chemins absolus" pour designer les fichiers voulus, mais on ne touche pas au répertoire courant. > > > si une application graphique ne devrais /jamais/ changer de répertoire > > courant, > > - est ce que c'est un domaine strictement réservé aux shells, > > - ou est ce qu'il y a d'autres cas de figure où c'est approprié qu'un > > logiciel le fasse ? > > Je pense qu'une application quelconque a plein de raison de changer de > répertoire courant (p.ex. lancer un logiciel complémentaire dans son > environnement propre), ah oui, ça pourrais m'arriver plus tard :-) (mais Il me semble que je pourrais aussi donner tous les paramètres en chemins absolus) > mais elle peut sauvegarder le répertoire > précédent et y revenir ok pour celui là, y a-t-il d'autres exemples ? pour la curiosité :-) > > > disons que, quelle que soit la méthode utilisée par l'application pour > > définir un chemin dont elle aura besoin au cours de sa vie, changer la > > structure des répertoires pendant qu'elle tourne est risqué : > > j'ai entendu dire que la pratique est de lire le fichier de config au > > démarrage, mais pas de vérifier régulièrement s'il a été modifié. > > C'est juste: il ne faudrait changer aucun des chemins absolus qui > figureraient dans la config. Par contre, si tout est exprimé > relativement au répertoire courant, le risque n'existe pas. il ne faudrait changer aucun des chemins qui figureraient dans la config. y compris la partie écrite des chemins relatifs. Par contre, si je t'ai bien compris, on peut changer le chemin du répertoire courant parce qu'il est "mémorisé sous forme de handle" (ou équivalent) > > >> Je ne sais pas, je ne sais toujours pas pourquoi ton programme a besoin > >> de créer des fichiers de logs plutôt que d'utiliser stdout et stderr, > > > > en plus, pas à la place. > > Ah, des logs supplémentaires? Pourquoi? - parce que je ne sens pas la prise en charge d'un wrapper script qui va marcher à tous les coups sur toutes les plateformes (voir l'autre branche du fil) - pour, à la fois, te contenter avec les sorties standards, et me contenter avec des fichiers écrits immédiatement > Comment? Combien? ça dépend comment on compte, mais en gros, chaque msg à logger est dupliqué (voire * 3 avec l'interface graphique). > > > c'est pour ça qu'il est imaginable d'ignorer les erreurs d'écriture > > quand il y en a, considérant que c'est rattrapable via stdout et stderr > > (mais en fait c'est ce que j'avais écrit juste avant, non ?) > > Je ne comprends pas ce que tu entends par erreur d'écriture et en > particulier avec stdout et stderr. si je te comprend bien, écrire sur stdout et stderr ne provoque jamais aucune erreur d'aucune sorte ? le pire qui puisse arriver, c'est que ce qu'on y envoie tombe dans un puits sans fond ? quand je reçois un msg à traiter, j'ai 3 interfaces à ma disposition : - les sorties standards - les fichiers de logs - l'interface graphique ce dont je parlais était d'ignorer les erreurs d'écriture dans les fichiers de logs, puisque les sorties standards suffisent pour récupérer l'information. cad de ne pas indiquer sur les sorties standards et dans l'interface graphique, qu'on a eu une erreur au moment d'écrire dans les fichiers de logs. -- RAPID maintainer http://savannah.nongnu.org/projects/rapid/
[toc] | [prev] | [next] | [standalone]
| From | Marc SCHAEFER <schaefer@alphanet.ch> |
|---|---|
| Date | 2021-09-20 12:29 +0000 |
| Message-ID | <si9urh$mad$1@shakotay.alphanet.ch> |
| In reply to | #7776 |
Thomas <fantome.forums.tDeContes@free.fr.invalid> wrote: > je n'ai pas entendu dire qu'on pouvait faire ça en ada, > ça doit être une fonction spécifique UNIX ? POSIX, oui. Ca fait 25 ans que je n'ai plus écrit d'Ada. > si je te comprend bien, l'avantage de se référer au répertoire courant, > sans le mémoriser ni le changer, c'est qu'il supporte les renommages en > cours d'exécution ? Voilà. > et si on supprime ce répertoire, qu'est ce que ça donne ? Le répertoire n'est plus accessible avec son nom, mais reste accessible à tous ceux qui ont encore son handle, avec quelques bizarreries: schaefer@reliand:~$ mkdir /tmp/tt schaefer@reliand:~$ cd /tmp/tt schaefer@reliand:/tmp/tt$ rmdir /tmp/tt schaefer@reliand:/tmp/tt$ ls schaefer@reliand:/tmp/tt$ touch abcd touch: cannot touch 'abcd': No such file or directory schaefer@reliand:/tmp/tt$ ls -la total 0 schaefer@reliand:/tmp/tt$ pwd /tmp/tt schaefer@reliand:/tmp/tt$ /bin/pwd /bin/pwd: couldn't find directory entry in '..' with matching i-node > bon, a priori, je n'ai pas besoin de pousser la résilience de mon > logiciel au point où on puisse le changer de place pendant son > exécution, C'était pour te faire comprendre la philosophie complètement différente de UNIX concernant les chemins. Il n'est en général pas une bonne pratique de `deviner' où est "son" répertoire. Soit c'est en dur (/etc/application/), ~/.application, etc), soit c'est une variable d'environnement, soit c'est configuré quelque part. Et changer le répertoire courant durant l'exécution, c'est changer la référence et donc on a des soucis pour tous les arguments de ligne de commande qui sont en fait des fichiers exprimés relativement (au répertoire courant au moment du lancement). >> le Filesystem Hierarchy Standard (même s'il devient apparemment >> obsolète). > > qu'est ce que c'est ? > (il a peut être besoin d'une mise à jour ?) https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard Apparemment c'est surtout que certaines distributions ont laissé tombé. > et là le rangement en sous-répertoires retrouve tout son intérêt pour > la commodité. C'est juste. > en fait, je pense que j'aurai l'occasion de faire une fenêtre de > "préférences", qui va éditer "en mode graphique" un fichier de ce genre > (donc ce fichier sera écrit et lu symétriquement, et pas édité à la > main). Dommage, j'adore quand je peux générer ce genre de fichier automatiquement, par exemple pour préconfigurer une salle de machines ou tester des applications automatiquement. Donc: configuration stocké en format texte, dans ~/.config/application/config par exemple. Quel format texte? Totalement égal si je peux le générer avec un template. > j'ai cru comprendre que pour permettre aux utilisateurs de Windows de > double cliquer sur un fichier pour l'ouvrir, il est nécessaire de Microsoft est pour moi hors sujet. > prendre en charge l'indication du fichier cliqué comme argument unique > (je ne sais pas comment ça se passe sur les autres plateformes) La plupart du temps le GUI va simplement lancer /usr/bin/toto nom-fichier-double-cliqué. Toutefois, la plupart des GUI permettent de configurer le comportement avec des templates (exemple: programme %f dans l'association MIME), il me semble. > donc, comment faire qqch qui réponde à ton besoin et qui soit compatible > avec ce comportement de Windows ? Si tu veux faire une application multi-plateforme, tu peux corriger les problèmes Microsoft soit dans ton application, soit simplement, et cela serait mon approche, livrer un wrapper (sous forme batch Microsoft ou autre) qui corrige les problèmes de compatibilité de cette plateforme ? Dans mon optique, le monde Microsoft ne m'intéresse pas, donc je ne vais pas trop élaborer. D'autant plus qu'on peut facilement tourner du Linux sur Microsoft aujourd'hui, y compris bientôt en mode graphique. > dans quels cas on peut vouloir exprimer un chemin relativement depuis un > autre répertoire ? C'était lié à ton file-browser qui change de répertoire courant. Le comportement recommandé est de ne pas changer de répertoire courant, pour que les noms de fichiers exprimés relativement en ligne de commande soient toujours ouverts au bon endroit sans devoir y préfixer le répertoire courant au moment du lancement du programme. > ok, quand on change de répertoire, on bascule en "tout en chemins > absolus" pour designer les fichiers voulus, mais on ne touche pas au > répertoire courant. Soit relatif au répertoire courant, soit absolu, à choix. >> mais elle peut sauvegarder le répertoire >> précédent et y revenir > > ok pour celui là, Sous forme de handle de préférence, car sous forme de chemin -> on revient au problème que le chemin est moins fort pour identifier que le handle. > y a-t-il d'autres exemples ? pour la curiosité :-) Aucune idée :) Je constate aussi qu'il y a un problème inhérent aux GUI ou plutôt aux applications qui n'acceptent pas d'être lancées deux fois. Exemple: je lance deux fois loffice dans deux répertoires différents. La construction même de loffice fait que le deuxième lancement ouvre en fait une deuxième fenêtre dans le 1er programme, avec l'environnement d'exécution du 1er programme (y.c. son répertoire courant). Pour moi, c'est un bug, mais c'est à quoi s'attendent les utilisateurs Microsoft et Apple. Comme quoi faire du GUI *et* de la ligne de commande c'est compliqué. gnumeric sous UNIX/X11 par exemple a le comportement auquel je m'attends, mais pas libreoffice. > - parce que je ne sens pas la prise en charge d'un wrapper script qui va > marcher à tous les coups sur toutes les plateformes > (voir l'autre branche du fil) Un script pour chaque plateforme, plutôt. > si je te comprend bien, écrire sur stdout et stderr ne provoque jamais > aucune erreur d'aucune sorte ? le pire qui puisse arriver, c'est que ce > qu'on y envoie tombe dans un puits sans fond ? Du point de vue de ton application, il est possible que l'écriture dans ces fichiers retourne une erreur, oui. A toi de la traiter (p.ex. en l'ignorant ou en la reportant au niveau supérieur: exemple: erreur d'écriture dans stdout -> warning unique dans stderr). > ce dont je parlais était d'ignorer les erreurs d'écriture dans les > fichiers de logs, puisque les sorties standards suffisent pour récupérer > l'information. Erreur d'écriture dans fichier de log -> erreur dans stderr et dialogue graphique vu que c'est quand même quelque chose de rare.
[toc] | [prev] | [next] | [standalone]
| From | Thomas <fantome.forums.tDeContes@free.fr.invalid> |
|---|---|
| Date | 2021-09-24 17:40 +0200 |
| Message-ID | <fantome.forums.tDeContes-D7C707.17401124092021@news.free.fr> |
| In reply to | #7781 |
In article <si9urh$mad$1@shakotay.alphanet.ch>, Marc SCHAEFER <schaefer@alphanet.ch> wrote: > Ca fait 25 ans que je n'ai plus écrit d'Ada. 8-o ??? tu as déjà programmé en Ada, et maintenant tu développes de l'embarqué en C ? ??? est-ce que tu as eu une super mauvaise expérience en Ada il y a 25 ans, ou est-ce qu'on t'impose à toutes forces ton environnement de développement ? il y a 25 ans, Ada95 venait de sortir, donc si tu n'a fait que du Ada83, il y en a eu des améliorations depuis ! ;-) POO, contrats, ... voilà une excellente présentation :-) https://www.youtube.com/watch?v=b5lRyBRk0d8 (j'adore le "langage épais" :-) ) > > bon, a priori, je n'ai pas besoin de pousser la résilience de mon > > logiciel au point où on puisse le changer de place pendant son > > exécution, > > C'était pour te faire comprendre la philosophie complètement différente > de UNIX concernant les chemins. je sais que c'est un peu spécial :-) je pense que si c'est moi qui l'avais fait, je l'aurais fait un peu différemment, genre plus intuitif ;-) > Il n'est en général pas une bonne > pratique de `deviner' où est "son" répertoire. Soit c'est en dur > (/etc/application/), ~/.application, etc), soit c'est une variable > d'environnement, soit c'est configuré quelque part. en fait, c'était déjà programmé dedans quand je l'ai repris, pour permettre au logiciel de trouver ses images, et je ne pensais pas que ça poserais des pbs de le réutiliser pour faire les fichiers de logs :-) alors je pense qu'à très court terme je vais faire comme ça quand même, parce que : - pour l'instant on ne peut pas l'installer, on ne peut le faire marcher que dans le répertoire des sources, - j'aimerais mieux, tant que je n'ai pas évolué, que tout ce qui concerne ce logiciel reste à l'intérieur de son répertoire, - je ne sens pas la prise en charge d'un wrapper script pour tout le monde. mais je garde bien en tête toutes tes recommandations, et je vais tacher au moins de le rendre configurable à moyen terme :-) en fait, ce que j'essaye de faire maintenant, c'est bien comprendre le pb ainsi que toutes les solutions, pour pouvoir bien concevoir les modules que je suis en train de revoir maintenant, de manière à ne pas devoir les revoir de fond en comble le jour où je revois d'autres modules pour m'approcher un peu plus de l'idéal (par exemple si j'ajoute la prise en charge d'un fichier de config dans 6 mois) > > Et changer le répertoire courant durant l'exécution, c'est changer > la référence et donc on a des soucis pour tous les arguments de ligne de > commande même si a priori on peut aussi juste lire les fichiers immédiatement à l'ouverture (typiquement, pour un fichier de config qu'on ne modifie pas, on peut faire ça), je ne vois pas l'intérêt de changer le répertoire courant, donc même si c'était comme ça quand je l'ai repris je vais le virer vite fait ;-) > > >> le Filesystem Hierarchy Standard (même s'il devient apparemment > >> obsolète). > > > > qu'est ce que c'est ? > > (il a peut être besoin d'une mise à jour ?) > > https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard effectivement, c'est bien précisé là : https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s08.html chaque application -> directement dans le "user's home directory" dans la note 7, ça parle de trucs que je ne connais pas, et pas un mot sur $HOME, même pas en mal ! est ce que $HOME est suffisamment fiable et portable quand même ? j'allais dire qu'ils devraient proposer des regroupements du genre ~/.config/ , mais en fait ils proposent la "XDG Base Directory Specification" <https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest. html> donc même si c'est pas absolument mon idéal, cette Spécification existe, allons-y ! amtha, ça serais bien que le Filesystem Hierarchy Standard insiste un peu plus, pour que tout le monde utilise la XDG Base Directory Specification :-) connais tu ça ? (c'est là d'où vient le ~/.config/ apparemment) à ton avis, est ce qu'il y a des prerequis pour utiliser cette Spécification ? si on décide de s'y mettre, - est ce qu'on peut juste prendre les petits morceaux qui nous plaisent ? (par exemple, regarder $XDG_DATA_HOME mais pas $XDG_DATA_DIRS ni $datadir, ou mettre une autre valeur par défaut que celle indiquée) - ou alors est ce qu'on doit la prendre en charge entièrement et rigoureusement, sous peine de fiche un gros bazar ? mais au fait, peut être considères-tu que les applications ne devraient juste pas essayer de s'en mêler, et que c'est aux intégrateurs de faire l'interface via le wrapper script ? > > Apparemment c'est surtout que certaines distributions ont laissé tombé. ah dommage (sais tu si elles avaient de bonnes raisons de le faire ?) > > > et là le rangement en sous-répertoires retrouve tout son intérêt pour > > la commodité. > > C'est juste. et la XDG Base Directory Specification y remédie :-) reste les developpeurs à convaincre, surtout ceux qui utilisent snap ;-) > > > en fait, je pense que j'aurai l'occasion de faire une fenêtre de > > "préférences", qui va éditer "en mode graphique" un fichier de ce genre > > (donc ce fichier sera écrit et lu symétriquement, et pas édité à la > > main). > > Dommage, j'adore quand je peux générer ce genre de fichier > automatiquement, par exemple pour préconfigurer une salle de machines > ou tester des applications automatiquement. > > Donc: configuration stocké en format texte, dans > ~/.config/application/config par exemple. > > Quel format texte? Totalement égal si je peux le générer avec un > template. ok, connais-tu un endroit (tutoriel ?) qui explique comment fonctionnent les templates ? > > > j'ai cru comprendre que pour permettre aux utilisateurs de Windows de > > double cliquer sur un fichier pour l'ouvrir, il est nécessaire de > > Microsoft est pour moi hors sujet. pour moi c'est pas hors sujet, parce que je sais qu'il y a des gens qui s'en sont servis, puisqu'il y a dans le code et dans le log SVN des notes concernant des corrections de bug pour que ça puisse mieux fonctionner sous Windows :-) donc je considère ça comme un prerequis du mainteneur qui me l'a confié ;-) même s'il ne me l'a pas dit comme ça, je considère que ça fait partie de ma mission de ne pas casser ce qui marche ;-) > > > prendre en charge l'indication du fichier cliqué comme argument unique > > (je ne sais pas comment ça se passe sur les autres plateformes) > > La plupart du temps le GUI va simplement lancer /usr/bin/toto > nom-fichier-double-cliqué. > Toutefois, la plupart des GUI permettent de > configurer le comportement avec des templates (exemple: programme %f > dans l'association MIME), il me semble. ok donc ça c'est le boulot de l'intégrateur. tant que je ne suis pas au point là dessus, je souhaite que ça puisse fonctionner sans intégration. > > > donc, comment faire qqch qui réponde à ton besoin et qui soit compatible > > avec ce comportement de Windows ? > Dans mon optique, le monde Microsoft ne m'intéresse pas, donc je ne > vais pas trop élaborer. pour la question précédente, en fait on dirait que Windows et les autres plateformes sont similaires. il faut juste trouver un mécanisme qui soit compatible avec ça sans wrapper script. donc pas de fichier de config obligatoire, mais tu as dit que ça pouvait être facultatif. il faudrait aussi que ça soit compatible avec la manière d'utiliser le logiciel ... mais non en fait, puisque je peux séparer la partie gui et la partie cli ... sauf que la partie cli aussi risque d'avoir besoin du fichier de config ... (une suggestion ?) > > dans quels cas on peut vouloir exprimer un chemin relativement depuis un > > autre répertoire ? > > C'était lié à ton file-browser qui change de répertoire courant. tu disais "sémantiquement, tu vas changer de répertoire à chaque fois que tu veux relativement exprimer un chemin depuis ce répertoire" ah oui, tu disais ça en lien avec le file-browser ? je croyais que c'était une généralité et qu'il y avait des cas où c'était vraiment utile. mais avec le file-browser ... comme toi, je ne vois pas l'intérêt de faire des bugs ailleurs ... > Je constate aussi qu'il y a un problème inhérent aux GUI ou plutôt aux > applications qui n'acceptent pas d'être lancées deux fois. > Pour moi, c'est un bug, mais c'est à quoi s'attendent les utilisateurs > Microsoft et Apple. je suis un futur-ex Apple ;-) mais il y a un truc qu'il faut que j'essaye de faire ;-) ne pas essayer d'être parfait des le début !!! :-D je me demande ce qu'il peut y avoir comme pb quand par exemple 2 instances veulent modifier le même fichier ... mais tant pis, cette affaire là je ne m'en occupe pas, je laisse ça aux OS, aux intégrateurs, aux utilisateurs ... > > Comme quoi faire du GUI *et* de la ligne de commande c'est compliqué. veux tu dire que tu recommandes de tjr lancer les applications GUI depuis un bureau GUI et pas depuis un terminal ? > > - parce que je ne sens pas la prise en charge d'un wrapper script qui va > > marcher à tous les coups sur toutes les plateformes > > (voir l'autre branche du fil) > > Un script pour chaque plateforme, plutôt. oui, donc voilà : il faut que ça puisse marcher sans. > > > si je te comprend bien, écrire sur stdout et stderr ne provoque jamais > > aucune erreur d'aucune sorte ? le pire qui puisse arriver, c'est que ce > > qu'on y envoie tombe dans un puits sans fond ? > > Du point de vue de ton application, il est possible que l'écriture dans > ces fichiers retourne une erreur, oui. ah bon ? concrètement, dans quels cas ça peut arriver ? > A toi de la traiter (p.ex. en > l'ignorant ou en la reportant au niveau supérieur: exemple: erreur > d'écriture dans stdout -> warning unique dans stderr). > > > ce dont je parlais était d'ignorer les erreurs d'écriture dans les > > fichiers de logs, puisque les sorties standards suffisent pour récupérer > > l'information. > > Erreur d'écriture dans fichier de log -> erreur dans stderr et dialogue > graphique vu que c'est quand même quelque chose de rare. une erreur d'écriture dans un fichier de log, surtout si on inclus l'ouverture en écriture, qui fait une erreur en cas d'interdiction, ça peut arriver si par exemple on installe mon logiciel mal fichu comme il est à un niveau système. mais surtout : d'après le reste du fil, j'ai cru comprendre que tu préférais plutôt que mon logiciel ne fasse pas de fichiers de log. alors j'ai eu tendance à considérer ça comme facultatif, cad : moi j'en veux, alors je les fait quand même, mais si pour une raison quelconque il y a un pb pour les faire, comme ça n'est pas un pb pour toi, j'ai juste à l'ignorer. donc par exemple : s'il y a un pb à la lecture du fichier de config, je ne connais pas encore l'emplacement des fichiers de log, mais c'est pas grave, puisque c'est facultatif on ne les fait pas, c'est simple. mais peut être que, tout en préférant les logiciels qui ne s'en mêlent pas, tu considères que si on dit dans le fichier de config qu'on veut des fichiers de log, alors ils doivent être vraiment faits ? et donc, doivent-ils aussi être complets ? s'il y a un pb à la lecture du fichier de config (ou avant), on ne sait même pas encore à ce moment là si on veut des fichiers de log ou pas : que fait-on avec les erreurs ou autres messages qui ont lieu à ce moment là ? que me suggères tu à cette étape ? :-) -- RAPID maintainer http://savannah.nongnu.org/projects/rapid/
[toc] | [prev] | [next] | [standalone]
| From | Marc SCHAEFER <schaefer@alphanet.ch> |
|---|---|
| Date | 2021-09-24 17:21 +0000 |
| Message-ID | <sil1ep$9g5$1@shakotay.alphanet.ch> |
| In reply to | #7788 |
Thomas <fantome.forums.tDeContes@free.fr.invalid> wrote:
> tu as déjà programmé en Ada, et maintenant tu développes de l'embarqué
> en C ?
Oui, et je précise: C, pas C++.
Mes langages préférés sont: Perl, C, bash.
> dans la note 7, ça parle de trucs que je ne connais pas, et pas un mot
> sur $HOME, même pas en mal !
> est ce que $HOME est suffisamment fiable et portable quand même ?
> mais au fait, peut être considères-tu que les applications ne devraient
> juste pas essayer de s'en mêler, et que c'est aux intégrateurs de faire
> l'interface via le wrapper script ?
J'ai assez tendance à aimer le `convention over configuration', tout en
laissant possible de configurer si on a envie.
> (sais tu si elles avaient de bonnes raisons de le faire ?)
Non, je ne me suis pas trop intéressé à ça.
>> Quel format texte? Totalement égal si je peux le générer avec un
>> template.
>
> ok,
> connais-tu un endroit (tutoriel ?) qui explique comment fonctionnent les
> templates ?
Exemple en bash:
cat > fichier <<EOF
variable=$ma_variable
EOF
Exemple plus compliqué qui génère des lettres depuis une base de
données, en Perl:
make_latex("template", "out.tex",
'CHER' => (($row[0] eq 'M') ? 'Cher' : 'Chère'),
'ADRESSE' => $a,
'SOMME' => $s,
'PRENOM' => $p,
'APAYER' => ($s > 0) ? 'true' : 'false');
avec un fichier template qui ressemble à:
\opening{%CHER% %PRENOM%,}
...
Exemple en Perl Mojolicious via TemplateToolkit qui génère de l'HTML:
<form action="/config" method="post">
<label>Filtre d'émetteur
<select name="from">
% foreach my $f (@{$filters}) {
<option value="<%= $f->id %>"<%= ($f->id eq $current_filter->{'from'}) ? " selected" : "" %>><%= $f->name %></option>
% }
</select>
</label>
<label>Filtre de thread
<select name="thread">
% foreach my $f (@{$filters}) {
<option value="<%= $f->id %>"<%= ($f->id eq $current_filter->{'thread'}) ? " selected" : "" %>><%= $f->name %></option>
% }
</select>
</label><br>
<input type="submit">
</form>
---> SI C'EST DU TEXTE, J'AIME!
> sauf que la partie cli aussi risque d'avoir besoin du fichier de config
> (une suggestion ?)
des valeurs par défaut s'il n'y a pas de config, p.ex. en dur
$HOME/nom-app/log etc.
> ah oui, tu disais ça en lien avec le file-browser ?
C'est toi qui as dit que ton file browser dans ton code changeait de
répertoire courant. Ou c'est ce dont je me rappelle.
> je me demande ce qu'il peut y avoir comme pb quand par exemple 2
> instances veulent modifier le même fichier ...
Il existe des verrous, et on peut informer l'utilisateur si c'est une
erreur de l'utilisateur. Si c'est le fonctionnement même de
l'application d'écrire dans le même fichier, ça semble un bug de
l'application?
>> Comme quoi faire du GUI *et* de la ligne de commande c'est compliqué.
>
> veux tu dire que tu recommandes de tjr lancer les applications GUI
> depuis un bureau GUI et pas depuis un terminal ?
Non, ça c'est égal.
Ce que je voulais dire est que de faire une application qui se comporte
comme j'ai envie en ligne de commande (avec des paramètres adaptés, etc)
et aussi en GUI est probablement complexe.
>> Du point de vue de ton application, il est possible que l'écriture dans
>> ces fichiers retourne une erreur, oui.
>
> ah bon ?
> concrètement, dans quels cas ça peut arriver ?
Disque plein? Si ce sont des logs ce n'est pas grave. Si ce sont des
données, il faut gérer l'erreur.
> d'après le reste du fil, j'ai cru comprendre que tu préférais plutôt que
> mon logiciel ne fasse pas de fichiers de log.
Oui, si c'est pour que personne ne les lise jamais ...
> donc par exemple : s'il y a un pb à la lecture du fichier de config, je
Tu peux écrire sur stderr "pas trouvé la config", ou, si le programme a
été lancé sans arguments de ligne de commande, supposer qu'il a été
lancé en GUI et là ouvrir un dialogue.
> tu considères que si on dit dans le fichier de config qu'on veut des
> fichiers de log, alors ils doivent être vraiment faits ?
Comme disait quelqu'un d'autre, on peut aussi imaginer d'activer ou non
le logging et le debugging.
> que me suggères tu à cette étape ? :-)
les erreurs il faut les communiquer à l'utilisateur, soit sous forme
d'un dialogue (GUI) soit sous forme d'une écriture dans stderr.
Les diagnostics de l'applications peuvent aller dans stdout ou dans un
fichier de log, mais peut-être qu'il faudrait les activer explicitement
dans la config.
[toc] | [prev] | [next] | [standalone]
| From | Thomas <fantome.forums.tDeContes@free.fr.invalid> |
|---|---|
| Date | 2021-09-26 01:15 +0200 |
| Message-ID | <fantome.forums.tDeContes-628825.01154726092021@news.free.fr> |
| In reply to | #7790 |
In article <sil1ep$9g5$1@shakotay.alphanet.ch>, Marc SCHAEFER <schaefer@alphanet.ch> wrote: > Thomas <fantome.forums.tDeContes@free.fr.invalid> wrote: > > tu as déjà programmé en Ada, et maintenant tu développes de l'embarqué > > en C ? > > Oui, et je précise: C, pas C++. > > Mes langages préférés sont: Perl, C, bash. ah, je n'aime pas tellement, bash. je préfère make de bcp, malgré le fait qu'on y retrouve un tas de défauts du C. par curiosité, est ce qu'il y a une raison précise, qui fait que tu n'as pas accroché avec Ada ?? :-) > > > dans la note 7, ça parle de trucs que je ne connais pas, et pas un mot > > sur $HOME, même pas en mal ! > > est ce que $HOME est suffisamment fiable et portable quand même ? > > > > mais au fait, peut être considères-tu que les applications ne devraient > > juste pas essayer de s'en mêler, et que c'est aux intégrateurs de faire > > l'interface via le wrapper script ? > > J'ai assez tendance à aimer le `convention over configuration', tout en > laissant possible de configurer si on a envie. j'aime bcp ce principe :-) j'en déduis que : - je peux chercher $HOME - je peux prendre en charge un peu (des morceaux) de XDG Base Directory Specification, je ne suis pas obligé de faire tout d'un coup. - je dois tjr prévoir une solution de secours. > >> Quel format texte? Totalement égal si je peux le générer avec un > >> template. > > > > ok, > > connais-tu un endroit (tutoriel ?) qui explique comment fonctionnent les > > templates ? > > Exemple en bash: > > cat > fichier <<EOF > variable=$ma_variable > EOF ça ne me parle pas assez, parce qu'il manque des explications autour pour que je comprenne les différentes "couches". mais si tu veux on peut voir ça plus tard : quand je saurai lire un fichier de config, je reviendrai te demander si ce que je fais te convient, ce qu'il te faut comme template, etc ... > ---> SI C'EST DU TEXTE, J'AIME! compris ;-) > >> Du point de vue de ton application, il est possible que l'écriture dans > >> ces fichiers retourne une erreur, oui. > > > > ah bon ? > > concrètement, dans quels cas ça peut arriver ? > > Disque plein? Si ce sont des logs ce n'est pas grave. Si ce sont des > données, il faut gérer l'erreur. Si ce sont des données, on log l'erreur comme d'habitude, aucun pb à l'horizon. Si ce sont des logs, et si on veut logger l'erreur, il faut faire très attention à ne pas tomber dans une boucle infinie ! surtout que comme le cas est rare, si on ne fait pas attention on a vite fait de ne pas s'en apercevoir ! mais si ce n'est pas grave, alors j'ai juste à ne pas logger l'erreur. et le seul pb restant à l'horizon est de se demander pourquoi il n'y a pas d'erreur enregistrée dans le fichier alors qu'on l'a demandé. (mais un Disque plein concerne tous les fichiers, alors ça fera la même erreur ailleurs, et elle sera à nouveau loggée) > > > d'après le reste du fil, j'ai cru comprendre que tu préférais plutôt que > > mon logiciel ne fasse pas de fichiers de log. > > Oui, si c'est pour que personne ne les lise jamais ... mon idée c'est pas que les gens les lisent, mais qu'ils puissent me les envoyer si je leur demande, sans d'abord avoir à trouver comment les faire, et ensuite à reproduire le pb :-) > > > donc par exemple : s'il y a un pb à la lecture du fichier de config, je > > Tu peux écrire sur stderr "pas trouvé la config", ou, si le programme a > été lancé sans arguments de ligne de commande, supposer qu'il a été > lancé en GUI et là ouvrir un dialogue. > > > tu considères que si on dit dans le fichier de config qu'on veut des > > fichiers de log, alors ils doivent être vraiment faits ? > > Comme disait quelqu'un d'autre, on peut aussi imaginer d'activer ou non > le logging et le debugging. > > > que me suggères tu à cette étape ? :-) > > les erreurs il faut les communiquer à l'utilisateur, soit sous forme > d'un dialogue (GUI) soit sous forme d'une écriture dans stderr. > > Les diagnostics de l'applications peuvent aller dans stdout ou dans un > fichier de log, mais peut-être qu'il faudrait les activer explicitement > dans la config. (diagnostics = debug ?) (j'ai tendance à faire un ET plutôt qu'un OU entre les différentes interfaces, est-ce un pb ?) (je ne détaille pas plus, je suppose que ça n'a pas assez d'importance et que ça ferais juste perdre du temps à tout le monde - je peux si tu le souhaites) ce que je déduis de tout ce que t'as écrit (juste après les exemples de templates), c'est que "ce n'est pas grave" de ne pas écrire de fichiers de log, même si on a dit dans le fichier de config qu'on en voulait, donc en cas de pb quelconque avec le fichier, je me contente de stderr plus éventuellement dialogue GUI. -- RAPID maintainer http://savannah.nongnu.org/projects/rapid/
[toc] | [prev] | [next] | [standalone]
| From | Marc SCHAEFER <schaefer@alphanet.ch> |
|---|---|
| Date | 2021-09-26 14:24 +0000 |
| Message-ID | <sipvq8$3u2$1@shakotay.alphanet.ch> |
| In reply to | #7797 |
Thomas <fantome.forums.tDeContes@free.fr.invalid> wrote: > par curiosité, est ce qu'il y a une raison précise, qui fait que tu n'as > pas accroché avec Ada ?? :-) Les environnements où j'ai fait de l'Ada utilisaient un translateur Ada vers C, je me suis dis que j'allais plutôt utiliser l'original que la copie? :) Non, en fait, aucun des systèmes que j'ai utilisés ou programmés (j'ai fait de l'écriture allant de drivers bas niveau à des OS intermédiaires, puis du web) n'avaient aucune relation avec l'Ada. > - je dois tjr prévoir une solution de secours. Ou planter avec un joli message d'erreur. > ce que je fais te convient, ce qu'il te faut comme template, etc ... Si c'est du texte, c'est l'intégrateur qui fera le template. > c'est que "ce n'est pas grave" de ne pas écrire de fichiers de log, même > si on a dit dans le fichier de config qu'on en voulait, > donc en cas de pb quelconque avec le fichier, je me contente de stderr > plus éventuellement dialogue GUI. Me semble sensé.
[toc] | [prev] | [next] | [standalone]
| From | Thomas <fantome.forums.tDeContes@free.fr.invalid> |
|---|---|
| Date | 2021-09-28 22:02 +0200 |
| Message-ID | <fantome.forums.tDeContes-48CB2A.22022928092021@news.free.fr> |
| In reply to | #7799 |
In article <sipvq8$3u2$1@shakotay.alphanet.ch>, Marc SCHAEFER <schaefer@alphanet.ch> wrote: > Thomas <fantome.forums.tDeContes@free.fr.invalid> wrote: > > c'est que "ce n'est pas grave" de ne pas écrire de fichiers de log, même > > si on a dit dans le fichier de config qu'on en voulait, > > donc en cas de pb quelconque avec le fichier, je me contente de stderr > > plus éventuellement dialogue GUI. > > Me semble sensé. je te remercie pour toute l'aide que tu m'as apportée, en ayant cette bonne discussion sur ce qui est acceptable ou pas de part et d'autre :-) et je te propose que ça soit le mot de la fin pour ce fil :-) je remercie aussi tous ceux qui sont intervenus pour donner leur avis, on a tjr besoin d'avis différents :-) bien sur, je veux bien poursuivre un peu avec Stéphane CARPENTIER s'il le souhaite, ou même avec d'autres s'il y en a qui veulent intervenir ou poursuivre :-) mais avec un bémol, c'est qu'avec Marc j'ai trouvé un équilibre qui nous convient à tous les 2, et si qqn vient dire qu'il n'es pas d'accord, ça risque de chambouler tous mes plans ... mais ce bémol ne doit pas limiter votre liberté d'expression :-) -- RAPID maintainer http://savannah.nongnu.org/projects/rapid/
[toc] | [prev] | [next] | [standalone]
| From | Stéphane CARPENTIER <sc@fiat-linux.fr> |
|---|---|
| Date | 2021-09-24 19:12 +0000 |
| Message-ID | <slrnsks8om.83t.sc@scarpet42p.localdomain> |
| In reply to | #7788 |
Le 24-09-2021, Thomas <fantome.forums.tDeContes@free.fr.invalid> a écrit : > > mais au fait, peut être considères-tu que les applications ne devraient > juste pas essayer de s'en mêler, et que c'est aux intégrateurs de faire > l'interface via le wrapper script ? On y arrive. Soit tu ne veux voire les choses que d'un côté applicatif. Dans ce cas, c'est simple, tu balances tout sur stdout et stderr et tu laisses les intégrateurs, admins systèmes et utilisateurs finaux gérer ce qu'ils en font comme ils le veulent. Si les logs sont perdus lancés en mode graphique, c'est pas grave, l'utilisateur a toujours la possibilité de lancer en ligne de commande (même le mode graphique) pour voir les logs qui l'intéressent sur le terminal le jour où il veut comprendre. Si le packageur, l'administrateur ou l'utilisateur final considère que les logs sont importants, il est possible de gérer le lancement en redirigeant les logs dans un fichier. C'est pas forcément ton problème. Soit tu veux absolument, écrire des logs dans un fichier et ça commence à être de l'administration système. Et c'est là que ça commence à être rigolo. D'abord, il faut que quoiqu'il arrive, l'absence de possibilité d'écrire tes logs ne puisse pas empêcher ton appli de tourner. Ça veut dire que dans ton code tu dois prendre en compte une mauvaise installation ou un mauvais lancement. Ensuite, il y a le packager qui doit pouvoir choisir le répertoire de logs par défaut lors de l'installation. Puis, l'admin système doit pouvoir en choisir un autre pour l'ensemble de ses utilisateurs. Puis, un utilisateur particulier doit pouvoir choisir où il met les logs pour lui. Avec la possibilité de changer les logs par une option lors du démarrage s'il veut faire un test. C'est pour ça qu'il faut bien que tu fasses attention à la préséance dans le choix des possibilités si c'est défini à plusieurs endroits. Il faut absolument que ce qui est écrit en dur dans ton code ne soit utilisé que si rien d'autre n'est trouvé. Il faut aussi que l'option en ligne de commande prenne le dessus sur toutes les variables d'environnement et fichiers de conf. De même que l'utilisateur final peut écrire dans son $HOME et pas dans /etc et donc /etc va être réservé à l'admin système ou au packager et être moins prioritaire que $HOME. 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. -- Si vous avez du temps à perdre : https://scarpet42.gitlab.io
[toc] | [prev] | [next] | [standalone]
| From | Thomas <fantome.forums.tDeContes@free.fr.invalid> |
|---|---|
| Date | 2021-09-26 03:23 +0200 |
| Message-ID | <fantome.forums.tDeContes-AD18A9.03233926092021@news.free.fr> |
| In reply to | #7793 |
In article <slrnsks8om.83t.sc@scarpet42p.localdomain>, Stéphane CARPENTIER <sc@fiat-linux.fr> wrote: > Le 24-09-2021, Thomas <fantome.forums.tDeContes@free.fr.invalid> a écrit : > > > > mais au fait, peut être considères-tu que les applications ne devraient > > juste pas essayer de s'en mêler, et que c'est aux intégrateurs de faire > > l'interface via le wrapper script ? > > On y arrive. pardon : - j'ai pas précisé, je pensais ça en combinaison avec le fichier de config, le wrapper script étant présent pour mettre à jour le fichier de config en cas de besoin. - Marc ne m'a (finalement) pas suggéré de méthode pour passer le fichier de config sur la ligne de commande à mes conditions, je suppose parce que le chercher à des emplacements définis lui convient, mais j'ai oublié que dans ce cas, si je veux que la XDG Base Directory Specification soit prise en charge, il faut que le logiciel gère lui-même au moins le morceau pour trouver le fichier de config (après, pour les autres fichiers, ça peut passer uniquement par le fichier de config) > > Soit tu ne veux voire les choses que d'un côté applicatif. Dans ce cas, > c'est simple, tu balances tout sur stdout et stderr et tu laisses les > intégrateurs, admins systèmes et utilisateurs finaux gérer ce qu'ils en > font comme ils le veulent. > Si les logs sont perdus lancés en mode > graphique, c'est pas grave, l'utilisateur a toujours la possibilité de > lancer en ligne de commande (même le mode graphique) pour voir les logs > qui l'intéressent sur le terminal le jour où il veut comprendre. mon souci c'est que si qqn a juste des bugs à faire remonter, faut pas que ça soit trop compliqué. c'est pas comme s'il lui prend simplement l'envie de regarder sous le capot. dans ce cas là c'est à lui de se remonter les manches. > Soit tu veux absolument, écrire des logs dans un fichier et ça commence > à être de l'administration système. Et c'est là que ça commence à être > rigolo. :-D (c'est rigolo, alors je rigole :-) ) > D'abord, il faut que quoiqu'il arrive, l'absence de possibilité > d'écrire tes logs ne puisse pas empêcher ton appli de tourner. Ça veut > dire que dans ton code tu dois prendre en compte une mauvaise > installation ou un mauvais lancement. aucun pb, en ada il suffit de rattraper toutes les exceptions. la seule question qui me tracassait était de savoir dans quelle mesure ces erreurs là avaient besoin d'être rapportées à leur tour, parce qu'il y a un risque de tomber dans une boucle infinie. mais si on n'a pas besoin de les rapporter, aucun pb :-) > > Ensuite, il y a le packager qui doit pouvoir choisir le répertoire de > logs par défaut lors de l'installation. Puis, l'admin système doit > pouvoir en choisir un autre pour l'ensemble de ses utilisateurs. Puis, > un utilisateur particulier doit pouvoir choisir où il met les logs pour > lui. Avec la possibilité de changer les logs par une option lors du > démarrage s'il veut faire un test. > > C'est pour ça qu'il faut bien que tu fasses attention à la préséance > dans le choix des possibilités si c'est défini à plusieurs endroits. Il > faut absolument que ce qui est écrit en dur dans ton code ne soit utilisé > que si rien d'autre n'est trouvé. Il faut aussi que l'option en ligne de > commande prenne le dessus sur toutes les variables d'environnement et > fichiers de conf. De même que l'utilisateur final peut écrire dans son > $HOME et pas dans /etc et donc /etc va être réservé à l'admin système ou > au packager et être moins prioritaire que $HOME. tout ça me parait un peu compliqué (pour l'instant), mais ce qui me parait simple c'est : - de tout balancer sur stdout et stderr en plus des fichiers, - qu'on puisse désactiver les fichiers si on les trouve encombrants, même si je veux qu'ils soient activés par defaut, comme ça on se retrouve dans le 1er cas. > > 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) - 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) ? -- RAPID maintainer http://savannah.nongnu.org/projects/rapid/
[toc] | [prev] | [next] | [standalone]
| From | Stéphane CARPENTIER <sc@fiat-linux.fr> |
|---|---|
| Date | 2021-09-26 16:45 +0000 |
| Message-ID | <slrnsl18t8.29t.sc@scarpet42p.localdomain> |
| In reply to | #7798 |
Le 26-09-2021, Thomas <fantome.forums.tDeContes@free.fr.invalid> a écrit : > In article <slrnsks8om.83t.sc@scarpet42p.localdomain>, > Stéphane CARPENTIER <sc@fiat-linux.fr> wrote: > >> Soit tu ne veux voire les choses que d'un côté applicatif. Dans ce cas, >> c'est simple, tu balances tout sur stdout et stderr et tu laisses les >> intégrateurs, admins systèmes et utilisateurs finaux gérer ce qu'ils en >> font comme ils le veulent. > >> Si les logs sont perdus lancés en mode >> graphique, c'est pas grave, l'utilisateur a toujours la possibilité de >> lancer en ligne de commande (même le mode graphique) pour voir les logs >> qui l'intéressent sur le terminal le jour où il veut comprendre. > > mon souci c'est que si qqn a juste des bugs à faire remonter, faut pas > que ça soit trop compliqué. Il n'y a rien de compliqué. Si tu balances tous tes logs sur ta sortie d'erreur, tu dis à l'utilisateur de tapper la commande « $> monsuperprogramme 2> fichier.log » et de t'envoyer le fichier « fichier.log » quand il a reproduit le bug. > c'est pas comme s'il lui prend simplement l'envie de regarder sous le > capot. dans ce cas là c'est à lui de se remonter les manches. Oui, mais pour se remonter les manches, il faut juste que tu lui permettes de le faire. >> D'abord, il faut que quoiqu'il arrive, l'absence de possibilité >> d'écrire tes logs ne puisse pas empêcher ton appli de tourner. Ça veut >> dire que dans ton code tu dois prendre en compte une mauvaise >> installation ou un mauvais lancement. > > aucun pb, en ada il suffit de rattraper toutes les exceptions. > > la seule question qui me tracassait était de savoir dans quelle mesure > ces erreurs là avaient besoin d'être rapportées à leur tour, parce qu'il > y a un risque de tomber dans une boucle infinie. Je ne suis pas sûr d'avoir été clair. Imaginons que la seule possibilité de configuration soit le fichier « /etc/monprog.config » qui est donc à la main de l'intégrateur et de l'admin système. Imaginons toujours que par erreur, la ligne correspondant à l'écriture des logs soit définie à « /bin/monprog.log ». T'as beau catcher toutes tes exceptions, tu les envoies où tes erreurs ? > mais si on n'a pas besoin de les rapporter, aucun pb :-) En fait, c'est ton programme, c'est toi qui doit savoir ce qui doit être rapporté. C'est toi qui dois savoir quels problèmes doivent être traités ou pas. Si le fichier de conf n'est pas trouvé, est-ce que tu as des valeurs par défaut qui lui permettent de fonctionner ou pas ? Est-ce que c'est un problème ou pas ? C'est toi qui dois le savoir. Le disque est saturé, tu ne peux pas écrire de logs. Soit. Mais est-ce que la saturation du disque peut poser d'autres problèmes à ton programme ? Pareil, je n'en sais rien, c'est à toi de le savoir. >> Ensuite, il y a le packager qui doit pouvoir choisir le répertoire de >> logs par défaut lors de l'installation. Puis, l'admin système doit >> pouvoir en choisir un autre pour l'ensemble de ses utilisateurs. Puis, >> un utilisateur particulier doit pouvoir choisir où il met les logs pour >> lui. Avec la possibilité de changer les logs par une option lors du >> démarrage s'il veut faire un test. >> >> C'est pour ça qu'il faut bien que tu fasses attention à la préséance >> dans le choix des possibilités si c'est défini à plusieurs endroits. Il >> faut absolument que ce qui est écrit en dur dans ton code ne soit utilisé >> que si rien d'autre n'est trouvé. Il faut aussi que l'option en ligne de >> commande prenne le dessus sur toutes les variables d'environnement et >> fichiers de conf. De même que l'utilisateur final peut écrire dans son >> $HOME et pas dans /etc et donc /etc va être réservé à l'admin système ou >> au packager et être moins prioritaire que $HOME. > > tout ça me parait un peu compliqué (pour l'instant), Je ne vois pas en quoi c'est plus compliqué que ce que tu écrivais en cherchant dans les variables systèmes ou les répertoires différents. Je te dis juste qu'il faut que tu fasses attention à l'ordre dans lequel tu vas chercher tes fichiers. > mais ce qui me parait simple c'est : > - de tout balancer sur stdout et stderr en plus des fichiers, Ça me semble suttout faire double emploi. >> 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) > - 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 ... Mon idée (enfin, c'est pas vraiment la mienne, c'est quand même assez classique), c'est que tu te programmes une fonction genre « sendlog(niveau,message) » Et qu'à chaque fois que tu veux envoyer un log, tu passes ton message à cette fonction avec le niveau de logs voulu. Par exemple, en mode debug, tu vas envoyer toutes les valeurs de tes variables lors d'appels de fonction dans les logs. Par contre, en mode nominal, ça va surtout te polluer tes logs et tu n'affiches que les erreurs (éventuellement les warnings). Et c'est ta fonction sendlog qui va choisir quoi faire de tes logs : poubelle si c'est pas le bon niveau de logs et envoi dans le cas contraire. Je ne sais pas si tu utilises un framework, ou si tu définis toutes tes fonctions, mais il doit bien exister quelque chose. > 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. Par exemple, la commande find, si tu cherches toto.txt avec « find / -name toto.txt » en tant que simple utilisateur, tu vas avoir l'écran rempli d'erreurs des répertoires que tu n'as pas le droit de lire. et s'il y a une réponse positive, tu ne vas pas la voir. Alors tu vas plutôt faire ta recherche avec un « find / -name toto.txt 2> /dev/null ». C'est pareil pour ton application, il faut qu'elle soit souple. -- Si vous avez du temps à perdre : https://scarpet42.gitlab.io
[toc] | [prev] | [next] | [standalone]
| From | Thomas <fantome.forums.tDeContes@free.fr.invalid> |
|---|---|
| Date | 2021-09-27 17:33 +0200 |
| Message-ID | <fantome.forums.tDeContes-CB5B35.17330627092021@news.free.fr> |
| In reply to | #7801 |
In article <slrnsl18t8.29t.sc@scarpet42p.localdomain>, Stéphane CARPENTIER <sc@fiat-linux.fr> wrote: > Le 26-09-2021, Thomas <fantome.forums.tDeContes@free.fr.invalid> a écrit : > > In article <slrnsks8om.83t.sc@scarpet42p.localdomain>, > > Stéphane CARPENTIER <sc@fiat-linux.fr> wrote: > > > >> Soit tu ne veux voire les choses que d'un côté applicatif. Dans ce cas, > >> Si les logs sont perdus lancés en mode > >> graphique, c'est pas grave, l'utilisateur a toujours la possibilité de > >> lancer en ligne de commande (même le mode graphique) pour voir les logs > >> qui l'intéressent sur le terminal le jour où il veut comprendre. > > > > mon souci c'est que si qqn a juste des bugs à faire remonter, faut pas > > que ça soit trop compliqué. > > Il n'y a rien de compliqué. Si tu balances tous tes logs sur ta sortie > d'erreur, tu dis à l'utilisateur de tapper la commande > « $> monsuperprogramme 2> fichier.log » > et de t'envoyer le fichier « fichier.log » quand il a reproduit le bug. et pour Windows, je vais sur un forum Windows pour demander comment faire, et ensuite je transmet à l'utilisateur la réponse qu'on me donne sans l'avoir pratiquée. ou alors je lui répond "vas sur un forum Windows pour demander comment on fait ça, moi je sais pas". > > > c'est pas comme s'il lui prend simplement l'envie de regarder sous le > > capot. dans ce cas là c'est à lui de se remonter les manches. > > Oui, mais pour se remonter les manches, il faut juste que tu lui > permettes de le faire. il me semble que nous n'avons pas de désaccord sur ce point précis. > > >> D'abord, il faut que quoiqu'il arrive, l'absence de possibilité > >> d'écrire tes logs ne puisse pas empêcher ton appli de tourner. Ça veut > >> dire que dans ton code tu dois prendre en compte une mauvaise > >> installation ou un mauvais lancement. > > > > aucun pb, en ada il suffit de rattraper toutes les exceptions. > > > > la seule question qui me tracassait était de savoir dans quelle mesure > > ces erreurs là avaient besoin d'être rapportées à leur tour, parce qu'il > > y a un risque de tomber dans une boucle infinie. > > Je ne suis pas sûr d'avoir été clair. Imaginons que la seule possibilité > de configuration soit le fichier « /etc/monprog.config » qui est donc à > la main de l'intégrateur et de l'admin système. Imaginons toujours que > par erreur, la ligne correspondant à l'écriture des logs soit définie à > « /bin/monprog.log ». T'as beau catcher toutes tes exceptions, tu les > envoies où tes erreurs ? sur stderr et dans un dialogue GUI. > > > mais si on n'a pas besoin de les rapporter, aucun pb :-) > > En fait, c'est ton programme, c'est toi qui doit savoir ce qui doit être > rapporté. je crois qu'on s'est entendu avec Marc sur le fait qu'il n'y avait pas de nécessité à cet endroit. et si qqn d'autre me fais changer d'avis plus tard ... tant pis, on pourra tjr l'améliorer plus tard. > >> Ensuite, il y a le packager qui doit pouvoir choisir le répertoire de > >> logs par défaut lors de l'installation. Puis, l'admin système doit > >> pouvoir en choisir un autre pour l'ensemble de ses utilisateurs. Puis, > >> un utilisateur particulier doit pouvoir choisir où il met les logs pour > >> lui. Avec la possibilité de changer les logs par une option lors du > >> démarrage s'il veut faire un test. > >> > >> C'est pour ça qu'il faut bien que tu fasses attention à la préséance > >> dans le choix des possibilités si c'est défini à plusieurs endroits. Il > >> faut absolument que ce qui est écrit en dur dans ton code ne soit utilisé > >> que si rien d'autre n'est trouvé. Il faut aussi que l'option en ligne de > >> commande prenne le dessus sur toutes les variables d'environnement et > >> fichiers de conf. De même que l'utilisateur final peut écrire dans son > >> $HOME et pas dans /etc et donc /etc va être réservé à l'admin système ou > >> au packager et être moins prioritaire que $HOME. > > > > tout ça me parait un peu compliqué (pour l'instant), > > Je ne vois pas en quoi c'est plus compliqué que ce que tu écrivais en > cherchant dans les variables systèmes ou les répertoires différents. > Je te dis juste qu'il faut que tu fasses attention à l'ordre dans lequel > tu vas chercher tes fichiers. oui, en regardant bien, tu as raison :-) comme c'est fastidieux je reporte, mais je prend bonne note de ce conseil là, qui me parait de bon sens :-) > > > mais ce qui me parait simple c'est : > > - de tout balancer sur stdout et stderr en plus des fichiers, > > Ça me semble suttout faire double emploi. mais ça ne dérange personne. et ça solutionne le pb que tu as posé ci dessus. > > >> Pour la séparation de stdout et stderr, c'est pas forcément très utile. > >> Il me semble préférable de tout mettre au même endroit avec un niveau de > >> log qui contient un tag et qui est paramétrable. Par exemple, tu mets du > >> DEBUG, INFO, WARNING et ERROR quand tu envoies tes logs avec un niveau > >> d'activation faible en temps normal pour avoir moins de lignes et tu > >> affiches tout quand tu veux comprendre ce qu'il se passe. > > > > j'aime bcp l'idée :-) > > > > je ne sais pas si c'est facile à faire très rapidement, parce que : > > - il faut que je définisse des règles pour catégoriser les logs > > (auj dans mon code les logs ne sont divisés qu'en 2 catégories : DEBUG > > et ERROR) (y a-t-il des règles pour déterminer la catégorie de chaque message ?) > Mon idée, c'est que tu te programmes une fonction genre > « sendlog(niveau,message) » > Et c'est ta fonction sendlog qui va choisir quoi faire de tes logs : > poubelle si c'est pas le bon niveau de logs et envoi dans le cas > contraire. ok, je comprend mieux :-) je croyais que tu disais de mettre un tag dans le fichier de log, pour pouvoir ensuite le relire en filtrant (par ex avec grep), et éventuellement le répartir en plusieurs fichiers par la suite. en fait tu dis juste de sélectionner ce qu'on affiche, et que c'est suffisant au niveau de l'ergonomie pour ne générer qu'un seul fichier de log. (dis moi si je me trompe à nouveau) > > Je ne sais pas si tu utilises un framework, ou si tu définis toutes tes > fonctions, mais il doit bien exister quelque chose. ça n'est pas une bibliothèque externe, c'est interne à RAPID, mais j'ai 2 procédures : `Debug(Msg);` et `Error(Msg);`, qui sont l'équivalent de `sendlog(DEBUG,Msg)` et `sendlog(ERROR,Msg)`. > > > est-ce que ça convient, d'avoir tous ces tags qui s'affichent dans le > > terminal quand on est en CLI (par ex au moment d'indiquer que les > > arguments sont mauvais) ? > > Si c'est une application qui tourne dans un terminal, faut pas que les > logs la rendent inutilisable. mais si j'ai bien compris, les tags ne sont pas censés se retrouver sur l'affichage. donc tout va bien :-) > Par exemple, la commande find, si tu > cherches toto.txt avec « find / -name toto.txt » en tant que simple > utilisateur, tu vas avoir l'écran rempli d'erreurs des répertoires que > tu n'as pas le droit de lire. et s'il y a une réponse positive, tu ne > vas pas la voir. Alors tu vas plutôt faire ta recherche avec un > « find / -name toto.txt 2> /dev/null ». (je n'avais pas encore eu le temps de demander comment faire ça, merci :-)) ) -- RAPID maintainer http://savannah.nongnu.org/projects/rapid/
[toc] | [prev] | [next] | [standalone]
| From | Stéphane CARPENTIER <sc@fiat-linux.fr> |
|---|---|
| Date | 2021-10-01 16:54 +0000 |
| Message-ID | <slrnslefar.16n.sc@scarpet42p.localdomain> |
| In reply to | #7803 |
Le 27-09-2021, Thomas <fantome.forums.tDeContes@free.fr.invalid> a écrit : > In article <slrnsl18t8.29t.sc@scarpet42p.localdomain>, > Stéphane CARPENTIER <sc@fiat-linux.fr> wrote: > >> Il n'y a rien de compliqué. Si tu balances tous tes logs sur ta sortie >> d'erreur, tu dis à l'utilisateur de tapper la commande >> « $> monsuperprogramme 2> fichier.log » >> et de t'envoyer le fichier « fichier.log » quand il a reproduit le bug. > > et pour Windows, > je vais sur un forum Windows pour demander comment faire, et ensuite je > transmet à l'utilisateur la réponse qu'on me donne sans l'avoir > pratiquée. > ou alors je lui répond "vas sur un forum Windows pour demander comment > on fait ça, moi je sais pas". Oui, bon, alors effectivement, Windows, je ne connais pas, je ne sais pas comment ça marche et c'est pas mon problème. Mes réponses sont orientées unix. Dans les grandes lignes ça doit pouvoir s'adapter sur Windows mais je ne sais pas comment. >> En fait, c'est ton programme, c'est toi qui doit savoir ce qui doit être >> rapporté. > > je crois qu'on s'est entendu avec Marc sur le fait qu'il n'y avait pas > de nécessité à cet endroit. > et si qqn d'autre me fais changer d'avis plus tard ... tant pis, on > pourra tjr l'améliorer plus tard. Ce que je veux dire, c'est que tu peux apporter une nouvelle fonctionnalité à ton programme et que cette fonctionnalité va nécessiter va nécessiter 10Go d'espace disque libre et que du coup, ça peut devenir important de se mettre à le logguer. >> >> Pour la séparation de stdout et stderr, c'est pas forcément très utile. >> >> Il me semble préférable de tout mettre au même endroit avec un niveau de >> >> log qui contient un tag et qui est paramétrable. Par exemple, tu mets du >> >> DEBUG, INFO, WARNING et ERROR quand tu envoies tes logs avec un niveau >> >> d'activation faible en temps normal pour avoir moins de lignes et tu >> >> affiches tout quand tu veux comprendre ce qu'il se passe. >> > >> > j'aime bcp l'idée :-) >> > >> > je ne sais pas si c'est facile à faire très rapidement, parce que : >> > - il faut que je définisse des règles pour catégoriser les logs >> > (auj dans mon code les logs ne sont divisés qu'en 2 catégories : DEBUG >> > et ERROR) > > (y a-t-il des règles pour déterminer la catégorie de chaque message ?) Ce que je te dis, c'est que c'est toi qui voit ce qui est important pour ton programme. Est-ce que c'est une erreur grave qui l'empêche de tourner ? Est-ce que c'est juste une précision du fichier de conf que tu as choisis ? Est-ce que c'est parce que ton programme a un comportement bizarre alors il faut tout logguer pour comprendre ce qu'il fait vraiment ligne par ligne ? >> Mon idée, c'est que tu te programmes une fonction genre >> « sendlog(niveau,message) » > >> Et c'est ta fonction sendlog qui va choisir quoi faire de tes logs : >> poubelle si c'est pas le bon niveau de logs et envoi dans le cas >> contraire. > > ok, je comprend mieux :-) > > je croyais que tu disais de mettre un tag dans le fichier de log, pour > pouvoir ensuite le relire en filtrant (par ex avec grep), et > éventuellement le répartir en plusieurs fichiers par la suite. Tu as les deux en fait. À partir du moment où tu reçois le niveau de log pour savoir s'il faut l'envoyer ou pas, tu mets le tag qui va bien dans tes logs. Quand tu es en mode debug, ça permet de chercher les erreurs graves au milieu des centaines de lignes d'information. De même qu'il faut mettre l'heure à laquelle tu loggues le message. Le tag et l'heure ne sont pas plus compliqués à ajouter mais tu en verras l'utilité le jour où tu auras des milliers de lignes de log à analyser. > en fait tu dis juste de sélectionner ce qu'on affiche, et que c'est > suffisant au niveau de l'ergonomie pour ne générer qu'un seul fichier de > log. > (dis moi si je me trompe à nouveau) Ce que je dis, c'est qu'en faisant les deux, tu peux tout mettre dans le même fichier de logs. Parce que des fois, tu as un log normal informatif qui arrive systématiquement juste avant une erreur grave et de faire la corrélation entre les deux va être dur si tu as des fichiers différents. En temps normal, tu regardes juste si tu as des erreurs pour savoir si tout est normal. En débuggage, tu cherches tes erreurs et tu lis le contexte autour. >> > est-ce que ça convient, d'avoir tous ces tags qui s'affichent dans le >> > terminal quand on est en CLI (par ex au moment d'indiquer que les >> > arguments sont mauvais) ? >> >> Si c'est une application qui tourne dans un terminal, faut pas que les >> logs la rendent inutilisable. > > mais si j'ai bien compris, les tags ne sont pas censés se retrouver sur > l'affichage. donc tout va bien :-) En quoi ça te gêne d'afficher les tags ? C'est pas plus compliqué, c'est juste un mot défini à rajouter. Et lorsque les sorties sont mélangées, c'est la seule façon de voir rapidement si c'est de l'affichage normal ou une alerte à traiter. >> Par exemple, la commande find, si tu >> cherches toto.txt avec « find / -name toto.txt » en tant que simple >> utilisateur, tu vas avoir l'écran rempli d'erreurs des répertoires que >> tu n'as pas le droit de lire. et s'il y a une réponse positive, tu ne >> vas pas la voir. Alors tu vas plutôt faire ta recherche avec un >> « find / -name toto.txt 2> /dev/null ». > > (je n'avais pas encore eu le temps de demander comment faire ça, > merci :-)) ) Pour le /dev/null c'est parce que tu ne veux mettre les messages d'erreurs directement à la poubelle. Mais si tu veux les envoyer par mail, tu mets un nom de fichier à la place. Sous Linux. Si tu veux, on peut s'arrêter là, tu poses des questions, moi je réponds. Ce que je te donne comme réponses, ce sont surtout les questions à te poser pour comprendre l'impact de ce que tu vas mettre en place. -- Si vous avez du temps à perdre : https://scarpet42.gitlab.io
[toc] | [prev] | [next] | [standalone]
| From | Thomas <fantome.forums.tDeContes@free.fr.invalid> |
|---|---|
| Date | 2021-10-22 23:41 +0200 |
| Message-ID | <fantome.forums.tDeContes-BF832B.23415822102021@news.free.fr> |
| In reply to | #7813 |
In article <slrnslefar.16n.sc@scarpet42p.localdomain>, Stéphane CARPENTIER <sc@fiat-linux.fr> wrote: > Le 27-09-2021, Thomas <fantome.forums.tDeContes@free.fr.invalid> a écrit : > > In article <slrnsl18t8.29t.sc@scarpet42p.localdomain>, > > Stéphane CARPENTIER <sc@fiat-linux.fr> wrote: > > > >> Il n'y a rien de compliqué. Si tu balances tous tes logs sur ta sortie > >> d'erreur, tu dis à l'utilisateur de tapper la commande > >> « $> monsuperprogramme 2> fichier.log » > >> et de t'envoyer le fichier « fichier.log » quand il a reproduit le bug. > > > > et pour Windows, > > je vais sur un forum Windows pour demander comment faire, et ensuite je > > transmet à l'utilisateur la réponse qu'on me donne sans l'avoir > > pratiquée. > > ou alors je lui répond "vas sur un forum Windows pour demander comment > > on fait ça, moi je sais pas". > > Oui, bon, alors effectivement, Windows, je ne connais pas, je ne sais > pas comment ça marche et c'est pas mon problème. Mes réponses sont > orientées unix. Dans les grandes lignes ça doit pouvoir s'adapter sur > Windows mais je ne sais pas comment. moi non plus je ne sais pas comment, et j'ai expliqué à Marc pourquoi j'en faisais mon problème quand même. d'où la solution de fabriquer les fichiers de log directement par l'exécutable, que je trouve la moins mauvaise, et la contrainte de te déranger le moins possible vient juste après ça, en termes de priorités. > > >> En fait, c'est ton programme, c'est toi qui doit savoir ce qui doit être > >> rapporté. > > > > je crois qu'on s'est entendu avec Marc sur le fait qu'il n'y avait pas > > de nécessité à cet endroit. > > et si qqn d'autre me fais changer d'avis plus tard ... tant pis, on > > pourra tjr l'améliorer plus tard. > > Ce que je veux dire, c'est que tu peux apporter une nouvelle > fonctionnalité à ton programme et que cette fonctionnalité va nécessiter > va nécessiter 10Go d'espace disque libre et que du coup, ça peut devenir > important de se mettre à le logguer. en fait quand je voyais le nb de cas de figures possibles, qui s'approche de 27, s'il fallait rapporter sur toutes les interfaces qui ne posent pas de pb tous les pbs des interfaces qui en posent, je me disais que c'était plus simple de tout ignorer. mais s'il n'y a que qqes cas particuliers dans lesquels c'est préférable de rapporter les pbs d'une interface sur une autre, ça devient bcp plus simple. :-) > > >> >> Pour la séparation de stdout et stderr, c'est pas forcément très utile. > >> >> Il me semble préférable de tout mettre au même endroit avec un niveau de > >> >> log qui contient un tag et qui est paramétrable. Par exemple, tu mets du > >> >> DEBUG, INFO, WARNING et ERROR quand tu envoies tes logs avec un niveau > >> >> d'activation faible en temps normal pour avoir moins de lignes et tu > >> >> affiches tout quand tu veux comprendre ce qu'il se passe. > >> > > >> > j'aime bcp l'idée :-) > >> > > >> > je ne sais pas si c'est facile à faire très rapidement, parce que : > >> > - il faut que je définisse des règles pour catégoriser les logs > >> > (auj dans mon code les logs ne sont divisés qu'en 2 catégories : DEBUG > >> > et ERROR) > > > > (y a-t-il des règles pour déterminer la catégorie de chaque message ?) > > Ce que je te dis, c'est que c'est toi qui voit ce qui est important pour > ton programme. Est-ce que c'est une erreur grave qui l'empêche de > tourner ? Est-ce que c'est juste une précision du fichier de conf que tu > as choisis ? Est-ce que c'est parce que ton programme a un comportement > bizarre alors il faut tout logguer pour comprendre ce qu'il fait > vraiment ligne par ligne ? ok. je devine que je trouverai l'usage au fur et à mesure que j'en aurai besoin. il faut que j'ai à l'idée qu'on peut ajouter autant de niveaux qu'on veut. en attendant, ça ne dérange personne que je reste à 2. :-) > > >> Mon idée, c'est que tu te programmes une fonction genre > >> « sendlog(niveau,message) » > > > >> Et c'est ta fonction sendlog qui va choisir quoi faire de tes logs : > >> poubelle si c'est pas le bon niveau de logs et envoi dans le cas > >> contraire. > > > > ok, je comprend mieux :-) > > > > je croyais que tu disais de mettre un tag dans le fichier de log, pour > > pouvoir ensuite le relire en filtrant (par ex avec grep), et > > éventuellement le répartir en plusieurs fichiers par la suite. > > Tu as les deux en fait. À partir du moment où tu reçois le niveau de log > pour savoir s'il faut l'envoyer ou pas, tu mets le tag qui va bien dans > tes logs. Quand tu es en mode debug, ça permet de chercher les erreurs > graves au milieu des centaines de lignes d'information. > > De même qu'il faut mettre l'heure à laquelle tu loggues le message. Le > tag et l'heure ne sont pas plus compliqués à ajouter mais tu en verras > l'utilité le jour où tu auras des milliers de lignes de log à analyser. C'est pas très compliqué à ajouter, surtout si on se contente de l'ajouter et peu importe ce que ça devient. C'est un tout petit peu plus compliqué que ça, si on veut se garantir de faire les choses "bien comme il faut", ce qui implique qques questions supplémentaires, même si à la fin on fait la même chose que sans se poser de question. par exemple : - si le msg à rapporter s'étale sur plusieurs lignes ? - est-ce qu'on le découpe en tranches et on remet les metadonnées sur chaque ligne ? - est-ce qu'on remplace le marqueur de fin de ligne par un autre séparateur ? - si on veut que ça soit exploitable en tableur il faut choisir un séparateur : lequel, et comment ça se passe si le msg à rapporter le contient ? > > > en fait tu dis juste de sélectionner ce qu'on affiche, et que c'est > > suffisant au niveau de l'ergonomie pour ne générer qu'un seul fichier de > > log. > > (dis moi si je me trompe à nouveau) > > Ce que je dis, c'est qu'en faisant les deux, tu peux tout mettre dans le > même fichier de logs. Parce que des fois, tu as un log normal informatif > qui arrive systématiquement juste avant une erreur grave et de faire la > corrélation entre les deux va être dur si tu as des fichiers différents. > > En temps normal, tu regardes juste si tu as des erreurs pour savoir si > tout est normal. En débuggage, tu cherches tes erreurs et tu lis le > contexte autour. je comprend bien l'intérêt :-) en suivant les recommandations de Marc, on peut choisir de tout mettre dans le même fichier de logs, soit en dirigeant les 2 sorties standards au même endroit, soit en donnant le même nom aux 2 fichiers. > > >> > est-ce que ça convient, d'avoir tous ces tags qui s'affichent dans le > >> > terminal quand on est en CLI (par ex au moment d'indiquer que les > >> > arguments sont mauvais) ? > >> > >> Si c'est une application qui tourne dans un terminal, faut pas que les > >> logs la rendent inutilisable. > > > > mais si j'ai bien compris, les tags ne sont pas censés se retrouver sur > > l'affichage. donc tout va bien :-) > > En quoi ça te gêne d'afficher les tags ? C'est pas plus compliqué, c'est > juste un mot défini à rajouter. Et lorsque les sorties sont mélangées, > c'est la seule façon de voir rapidement si c'est de l'affichage normal > ou une alerte à traiter. C'est pas compliqué, le pb c'est tjr de savoir ce qui est bien. je trouverais ça bizarre d'avoir le msg "ignoring unknown switch" ainsi que le "usage: ..." qui suit, bardés de tags + horodatage ! est-ce que ça se pratique ? > > >> Par exemple, la commande find, si tu > >> cherches toto.txt avec « find / -name toto.txt » en tant que simple > >> utilisateur, tu vas avoir l'écran rempli d'erreurs des répertoires que > >> tu n'as pas le droit de lire. et s'il y a une réponse positive, tu ne > >> vas pas la voir. Alors tu vas plutôt faire ta recherche avec un > >> « find / -name toto.txt 2> /dev/null ». > Pour le /dev/null c'est parce que tu ne veux mettre les messages > d'erreurs directement à la poubelle. je n'ai pas compris. "ne" est en trop ? > Ce que je te donne comme réponses, ce sont surtout les > questions à te poser pour comprendre l'impact de ce que tu vas mettre en > place. merci :-) -- RAPID maintainer http://savannah.nongnu.org/projects/rapid/
[toc] | [prev] | [next] | [standalone]
| From | Thomas <fantome.forums.tDeContes@free.fr.invalid> |
|---|---|
| Date | 2021-12-19 19:19 +0100 |
| Message-ID | <fantome.forums.tDeContes-B2A88C.19191319122021@news.free.fr> |
| In reply to | #7852 |
In article <fantome.forums.tDeContes-BF832B.23415822102021@news.free.fr>, Thomas <fantome.forums.tDeContes@free.fr.invalid> wrote: > In article <slrnslefar.16n.sc@scarpet42p.localdomain>, > Stéphane CARPENTIER <sc@fiat-linux.fr> wrote: > > > Le 27-09-2021, Thomas <fantome.forums.tDeContes@free.fr.invalid> a écrit : > > > In article <slrnsl18t8.29t.sc@scarpet42p.localdomain>, > > > Stéphane CARPENTIER <sc@fiat-linux.fr> wrote: > > >> En fait, c'est ton programme, c'est toi qui doit savoir ce qui doit être > > >> rapporté. > > > > > > je crois qu'on s'est entendu avec Marc sur le fait qu'il n'y avait pas > > > de nécessité à cet endroit. > > > et si qqn d'autre me fais changer d'avis plus tard ... tant pis, on > > > pourra tjr l'améliorer plus tard. > > > > Ce que je veux dire, c'est que tu peux apporter une nouvelle > > fonctionnalité à ton programme et que cette fonctionnalité va nécessiter > > va nécessiter 10Go d'espace disque libre et que du coup, ça peut devenir > > important de se mettre à le logguer. > > en fait quand je voyais le nb de cas de figures possibles, qui > s'approche de 27, > s'il fallait rapporter sur toutes les interfaces qui ne posent pas de pb > tous les pbs des interfaces qui en posent, > je me disais que c'était plus simple de tout ignorer. > > mais s'il n'y a que qqes cas particuliers dans lesquels c'est préférable > de rapporter les pbs d'une interface sur une autre, ça devient bcp plus > simple. :-) d'après moi : - on peut tout ignorer en cas de pb avec l'interface graphique, parce que ça ne peut pas arriver uniquement à cet endroit, ça arrivera forcément ailleurs. - on peut tout ignorer en cas de pb avec les fichiers de log, parce que c'est facultatif. si je t'ai bien compris : en cas de pb avec stdout / stderr, - si l'interface graphique est disponible, on affiche ça dedans, parce que dans ce cas c'est probable que stdout et stderr ne soient pas lus (redirigés ou jetés). - si non, on l'envoie sur stdout, parce que dans ce cas c'est probable que stderr ne soit pas lu (redirigé), mais c'est probable que stdout le soit (directement dans un terminal). - dans tous les cas, si on obtient des erreurs supplémentaires, on les ignore. est-ce que ça te parait correct ? > > >> >> Par exemple, tu mets > > >> >> du > > >> >> DEBUG, INFO, WARNING et ERROR quand tu envoies tes logs avec un > > >> >> niveau > > >> >> d'activation faible en temps normal est-ce que je numérote dans cet ordre de 0 à 3 ? -- RAPID maintainer http://savannah.nongnu.org/projects/rapid/
[toc] | [prev] | [next] | [standalone]
| From | Thomas <fantome.forums.tDeContes@free.fr.invalid> |
|---|---|
| Date | 2021-12-28 12:18 +0100 |
| Message-ID | <fantome.forums.tDeContes-06C52B.12184728122021@news.free.fr> |
| In reply to | #7892 |
In article <fantome.forums.tDeContes-B2A88C.19191319122021@news.free.fr>, Thomas <fantome.forums.tDeContes@free.fr.invalid> wrote: > > > >> >> Par exemple, tu mets > > > >> >> du > > > >> >> DEBUG, INFO, WARNING et ERROR quand tu envoies tes logs avec un > > > >> >> niveau > > > >> >> d'activation faible en temps normal > > est-ce que je numérote dans cet ordre de 0 à 3 ? peut-être plutôt dans l'autre sens : en commençant par le plus important et en allant vers le plus facultatif. dis moi si t'y vois un inconvénient. -- RAPID maintainer http://savannah.nongnu.org/projects/rapid/
[toc] | [prev] | [next] | [standalone]
| From | Stéphane CARPENTIER <sc@fiat-linux.fr> |
|---|---|
| Date | 2021-12-28 15:56 +0000 |
| Message-ID | <slrnssmcu2.hi0.sc@scarpet42p.localdomain> |
| In reply to | #7892 |
Le 19-12-2021, Thomas <fantome.forums.tDeContes@free.fr.invalid> a écrit : > > - on peut tout ignorer en cas de pb avec l'interface graphique, parce > que ça ne peut pas arriver uniquement à cet endroit, ça arrivera > forcément ailleurs. Ben justement voilà justement une bonne raison de ne pas chercher à logguer à plein d'endroits différents en fonction du contexte. Imagine, ton application elle tourne nickel en terminal. Ton utilisateur veut l'utiliser avec l'interface graphique. Sauf que comme tu n'as pas exactement les mêmes librairies avec Wayland et Xorg, ça peut marcher sur l'un et pas sur l'autre. Si tu veux analyser tous les cas possibles, ça va être très délicat. Si tu te contentes de balancer les logs et de laisser l'utilisateur en faire ce qu'il veut ça te simplifie la vie. > en cas de pb avec stdout / stderr, Ce qui est bien avec stdout/stderr, c'est que s'il y a un problème, l'utilisateur le redirige vers un autre endroit où il n'y a pas de problème. > - si l'interface graphique est disponible, on affiche ça dedans, > parce que dans ce cas c'est probable que stdout et stderr ne soient pas > lus (redirigés ou jetés). L'affichage dans l'interface graphique, c'est pour afficher une information qui demande une intervention de l'utilisateur à un moment. C'est pas forcément une erreur. Par exemple, si l'utilisateur n'a pas choisi la couleur de son fond d'écran mais que tu as une couleur par défaut, c'est pas très important. Lorsqu'il change la couleur de son fond d'écran mais qu'il y a un problème et que tu gardes la couleur par défaut, il faut l'informer que son action s'est mal passée. Si par contre, ton application exécute une action en tâche de fond toutes les minutes, si l'action plante une fois sur deux, il faut le logguer mais ne pas lui afficher la pop-up toutes les deux minutes. Ce n'est pas forcément grave si stdout et stderr ne sont pas lus. Si l'utilisateur veut chercher à comprendre après coup, il les lira. > - si non, on l'envoie sur stdout, > parce que dans ce cas c'est probable que stderr ne soit pas lu > (redirigé), > mais c'est probable que stdout le soit (directement dans un terminal). En fait, l'intérêt de sdout et de stderr, c'est que tu t'en cognes de savoir si c'est lu ou pas, redirigé ou pas. Tu donnes une information et l'utilisateur en fait ce qu'il veut. La différence entre les deux, c'est que le stdout, c'est pour l'information normale et le stderr c'est pour l'erreur. Par exemple, si ton application exécute une tâche de fond toutes les minutes, dans ton stdout, tu vas logguer le début et la fin de l'action. Et s'il y a un plantage, tu loggues l'erreur dans le stderr. Comme ça, si l'utilisateur redirige tout dans le même fichier, il aura le contexte : le plantage aura eu lieu pendant la tâche de fond. Mais s'il veut se concentrer sur les erreurs, il ne regarde que stderr. Tu le laisses choisir le niveau d'information qu'il veut afficher. Et si dans tes logs, tu précises ce que c'est (avec un timestamp devant) : INFO: début de la tâche de fond INFO: 42 informations à mettre à jour WARNING: 1 mise à jour est vide, utilisation de la valeur TOTO ERROR: enregistrement impossible, droits insuffisants INFO: fin de la tâche de fond Là, comme en général, tu vas avoir des centaines de lignes d'info pour quelques lignes d'erreur, il va pouvoir faire des recherches faciles. >> > >> >> Par exemple, tu mets >> > >> >> du >> > >> >> DEBUG, INFO, WARNING et ERROR quand tu envoies tes logs avec un >> > >> >> niveau >> > >> >> d'activation faible en temps normal > > est-ce que je numérote dans cet ordre de 0 à 3 ? En général, le plus simple est d'utiliser un framework qui fait déjà tout ça et de suivre la doc. -- Si vous avez du temps à perdre : https://scarpet42.gitlab.io
[toc] | [prev] | [next] | [standalone]
| From | Thomas <fantome.forums.tDeContes@free.fr.invalid> |
|---|---|
| Date | 2022-01-02 00:54 +0100 |
| Message-ID | <fantome.forums.tDeContes-E3C660.00542502012022@news.free.fr> |
| In reply to | #7894 |
In article <slrnssmcu2.hi0.sc@scarpet42p.localdomain>, Stéphane CARPENTIER <sc@fiat-linux.fr> wrote: > Le 19-12-2021, Thomas <fantome.forums.tDeContes@free.fr.invalid> a écrit : > > en cas de pb avec stdout / stderr, > > Ce qui est bien avec stdout/stderr, c'est que s'il y a un problème, > l'utilisateur le redirige vers un autre endroit où il n'y a pas de > problème. pour ça il faut qu'il s'aperçoive du pb, puis qu'il redémarre l'application avec les bons paramètres. c'est pour ça (je crois) que tu m'avais dit que c'était pas bien d'ignorer les erreurs. > Si par contre, ton application exécute une action en tâche de fond > toutes les minutes, si l'action plante une fois sur deux, il faut le > logguer mais ne pas lui afficher la pop-up toutes les deux minutes. Ce > n'est pas forcément grave si stdout et stderr ne sont pas lus. Si > l'utilisateur veut chercher à comprendre après coup, il les lira. si le disque est plein, - il faut le logguer ou ? - tu trouves que ça ne convient pas de signaler ce pb dans l'interface graphique ? ça ne convient pas de considérer que ce pb doit être résolu immédiatement pour que le logiciel puisse continuer à fonctionner correctement ? > > > > - si non, on l'envoie sur stdout, > > parce que dans ce cas c'est probable que stderr ne soit pas lu > > (redirigé), > > mais c'est probable que stdout le soit (directement dans un terminal). > > En fait, l'intérêt de sdout et de stderr, c'est que tu t'en cognes de > savoir si c'est lu ou pas, redirigé ou pas. Tu donnes une information et > l'utilisateur en fait ce qu'il veut. et si le disque est plein ? > > La différence entre les deux, c'est que le stdout, c'est pour > l'information normale et le stderr c'est pour l'erreur. Par exemple, si > ton application exécute une tâche de fond toutes les minutes, dans ton > stdout, tu vas logguer le début et la fin de l'action. Et s'il y a un > plantage, tu loggues l'erreur dans le stderr. > > Comme ça, si l'utilisateur redirige tout dans le même fichier, il aura > le contexte : le plantage aura eu lieu pendant la tâche de fond. Mais > s'il veut se concentrer sur les erreurs, il ne regarde que stderr. Tu le > laisses choisir le niveau d'information qu'il veut afficher. c'est comme ça que je suis parti pour l'instant. > > Et si dans tes logs, tu précises ce que c'est (avec un timestamp devant) : > INFO: début de la tâche de fond > INFO: 42 informations à mettre à jour > WARNING: 1 mise à jour est vide, utilisation de la valeur TOTO > ERROR: enregistrement impossible, droits insuffisants > INFO: fin de la tâche de fond > > Là, comme en général, tu vas avoir des centaines de lignes d'info pour > quelques lignes d'erreur, il va pouvoir faire des recherches faciles. a priori c'est une idée que je trouve pas mauvaise. mais il y a des questions non répondues, dans mon msg du 22 Oct 2021, qui font que je n'y vais pas pour l'instant. > > >> > >> >> Par exemple, tu mets > >> > >> >> du > >> > >> >> DEBUG, INFO, WARNING et ERROR quand tu envoies tes logs avec un > >> > >> >> niveau > >> > >> >> d'activation faible en temps normal > > > > est-ce que je numérote dans cet ordre de 0 à 3 ? > > En général, le plus simple est d'utiliser un framework qui fait déjà > tout ça et de suivre la doc. en ada, on a à ma connaissance toutes les bibliothèques nécessaires pour avoir toutes les possibilités de développement à disposition, mais il n'y a pas autant de bibliothèques qu'en c quand même. je suppose que c'est pour ça que mon prédécesseur avant démarré l'écriture d'une telle bibliothèque. je l'ai immédiatement "améliorée" en ajoutant la génération de fichiers log, parce que c'était un besoin et que je ne savais pas que c'était mal vu. et là, je continue de l'améliorer, par ex en rendant ces fichiers log facultatifs, et en permettant de choisir leur nom. -- RAPID maintainer http://savannah.nongnu.org/projects/rapid/
[toc] | [prev] | [next] | [standalone]
Page 2 of 5 — ← Prev page 1 [2] 3 4 5 Next page →
Back to top | Article view | fr.comp.os.unix
csiph-web