On 2021-07-23, Thomas wrote:du coup l'intégrateur met tous les logs dans le même fichier ? et c'est
pas gênant ?
L'intégrateur fait ce qu'il veut,
ça n'a pas une grande importance.
(et STDOUT est fait pour quoi ?)
C'est la sortie standard, c'est pour échanger avec l'applicatif (pour
une appli en ligne de commande). Sur une appli graphique, ça sert Í rien.
- S'en fiche (ce que font 99% des applications graphiques).
veux tu dire qu'elles produisent quand même des logs, mais qu'elles s'en
fichent d'écraser les logs précédents ou d'en avoir qui montent jusqu'Í
l'infini ?
Lance un firefox en ligne de commande, tu vas t'apercevoir qu'il va
afficher plein de choses sur la console. Pour une utilisation
courante, on s'en fiche.
On 2021-07-23, Thomas <fantome.forums.tDeContes@free.fr.invalid> wrote:
> du coup l'intégrateur met tous les logs dans le même fichier ? et c'est
> pas gênant ?
L'intégrateur fait ce qu'il veut,
ça n'a pas une grande importance.
> (et STDOUT est fait pour quoi ?)
C'est la sortie standard, c'est pour échanger avec l'applicatif (pour
une appli en ligne de commande). Sur une appli graphique, ça sert Í rien.
>> - S'en fiche (ce que font 99% des applications graphiques).
>
> veux tu dire qu'elles produisent quand même des logs, mais qu'elles s'en
> fichent d'écraser les logs précédents ou d'en avoir qui montent jusqu'Í
> l'infini ?
Lance un firefox en ligne de commande, tu vas t'apercevoir qu'il va
afficher plein de choses sur la console. Pour une utilisation
courante, on s'en fiche.
On 2021-07-23, Thomas wrote:du coup l'intégrateur met tous les logs dans le même fichier ? et c'est
pas gênant ?
L'intégrateur fait ce qu'il veut,
ça n'a pas une grande importance.
(et STDOUT est fait pour quoi ?)
C'est la sortie standard, c'est pour échanger avec l'applicatif (pour
une appli en ligne de commande). Sur une appli graphique, ça sert Í rien.
- S'en fiche (ce que font 99% des applications graphiques).
veux tu dire qu'elles produisent quand même des logs, mais qu'elles s'en
fichent d'écraser les logs précédents ou d'en avoir qui montent jusqu'Í
l'infini ?
Lance un firefox en ligne de commande, tu vas t'apercevoir qu'il va
afficher plein de choses sur la console. Pour une utilisation
courante, on s'en fiche.
Le 22-07-2021, Thomas a écrit :In article <60f83dc1$0$3743$,
Nicolas George <nicolas$ wrote:Thomas , dans le message
, a écrit :
> dans ce cas, pourrais tu m'aider Í le poser mieux, stp ?
Désolé, je n'ai pas vraiment l'énergie.
ah bon. tant pis, dommage.
(si tu l'avais eue, je suis sur que j'aurais pu bcp apprendre,
même s'il serait forcément resté qques points de désaccords dus Í ce que
j'ai déjÍ appris ailleurs et Í la différence des environnements et
contextes dans lesquels chacun évolue.)
Je crois que ce que Nicolas veut t'expliquer (ainsi que Marc en fait),
c'est que tu dis que tu ne veux t'en occuper que d'un point de vue
développeur et pas administrateur système, mais toutes tes questions
sont orientée administration système.
J'ai eu l'impression que tu l'avais compris Í un moment mais avec
d'autres réponses de ta part je n'en suis pas sÍ»r.
En gros, le développeur, il balance tout ce qui ne s'affiche pas dans
l'interface graphique dans stout et dans stderr. Point bare. Tout le
reste, c'est de l'administration système.
Techniquement parlant, le développeur de l'application peut choisir un
nom de fichier pour ses logs. Mais c'est juste de l'ingérence dans
l'administration système.
Ça n'a aucun sens de demander des bonnes
pratiques de nomage de fichiers de logs d'un point de vue développeur et
pas administrateur système.
Tout ce que tu veux faire en plus de stderr et stdout va juste
compliquer les choses Í celui qui veut mettre en place une politique de
logrotate.
Le 22-07-2021, Thomas <fantome.forums.tDeContes@free.fr.invalid> a écrit :
> In article <60f83dc1$0$3743$426a74cc@news.free.fr>,
> Nicolas George <nicolas$george@salle-s.org> wrote:
>
>> Thomas , dans le message
>> <fantome.forums.tDeContes-8A99BF.23331420072021@news.free.fr>, a écrit :
>> > dans ce cas, pourrais tu m'aider Í le poser mieux, stp ?
>>
>> Désolé, je n'ai pas vraiment l'énergie.
>
> ah bon. tant pis, dommage.
>
> (si tu l'avais eue, je suis sur que j'aurais pu bcp apprendre,
> même s'il serait forcément resté qques points de désaccords dus Í ce que
> j'ai déjÍ appris ailleurs et Í la différence des environnements et
> contextes dans lesquels chacun évolue.)
Je crois que ce que Nicolas veut t'expliquer (ainsi que Marc en fait),
c'est que tu dis que tu ne veux t'en occuper que d'un point de vue
développeur et pas administrateur système, mais toutes tes questions
sont orientée administration système.
J'ai eu l'impression que tu l'avais compris Í un moment mais avec
d'autres réponses de ta part je n'en suis pas sÍ»r.
En gros, le développeur, il balance tout ce qui ne s'affiche pas dans
l'interface graphique dans stout et dans stderr. Point bare. Tout le
reste, c'est de l'administration système.
Techniquement parlant, le développeur de l'application peut choisir un
nom de fichier pour ses logs. Mais c'est juste de l'ingérence dans
l'administration système.
Ça n'a aucun sens de demander des bonnes
pratiques de nomage de fichiers de logs d'un point de vue développeur et
pas administrateur système.
Tout ce que tu veux faire en plus de stderr et stdout va juste
compliquer les choses Í celui qui veut mettre en place une politique de
logrotate.
Le 22-07-2021, Thomas a écrit :In article <60f83dc1$0$3743$,
Nicolas George <nicolas$ wrote:Thomas , dans le message
, a écrit :
> dans ce cas, pourrais tu m'aider Í le poser mieux, stp ?
Désolé, je n'ai pas vraiment l'énergie.
ah bon. tant pis, dommage.
(si tu l'avais eue, je suis sur que j'aurais pu bcp apprendre,
même s'il serait forcément resté qques points de désaccords dus Í ce que
j'ai déjÍ appris ailleurs et Í la différence des environnements et
contextes dans lesquels chacun évolue.)
Je crois que ce que Nicolas veut t'expliquer (ainsi que Marc en fait),
c'est que tu dis que tu ne veux t'en occuper que d'un point de vue
développeur et pas administrateur système, mais toutes tes questions
sont orientée administration système.
J'ai eu l'impression que tu l'avais compris Í un moment mais avec
d'autres réponses de ta part je n'en suis pas sÍ»r.
En gros, le développeur, il balance tout ce qui ne s'affiche pas dans
l'interface graphique dans stout et dans stderr. Point bare. Tout le
reste, c'est de l'administration système.
Techniquement parlant, le développeur de l'application peut choisir un
nom de fichier pour ses logs. Mais c'est juste de l'ingérence dans
l'administration système.
Ça n'a aucun sens de demander des bonnes
pratiques de nomage de fichiers de logs d'un point de vue développeur et
pas administrateur système.
Tout ce que tu veux faire en plus de stderr et stdout va juste
compliquer les choses Í celui qui veut mettre en place une politique de
logrotate.
Voire encore mieux : une application graphique, souvent on la lance
elle-même depuis un bureau graphique, et on ne voit jamais les sorties
standard, donc elle ne devrait strictement rien écrire dessus Í part en cas
d'échec catastrophique.
Il peut bien sͻr y avoir des exceptions, mais comme justement ce sont des
exceptions, on ne peut rien dire sans savoir en quoi ce sont des exceptions.
Voire encore mieux : une application graphique, souvent on la lance
elle-même depuis un bureau graphique, et on ne voit jamais les sorties
standard, donc elle ne devrait strictement rien écrire dessus Í part en cas
d'échec catastrophique.
Il peut bien sͻr y avoir des exceptions, mais comme justement ce sont des
exceptions, on ne peut rien dire sans savoir en quoi ce sont des exceptions.
Voire encore mieux : une application graphique, souvent on la lance
elle-même depuis un bureau graphique, et on ne voit jamais les sorties
standard, donc elle ne devrait strictement rien écrire dessus Í part en cas
d'échec catastrophique.
Il peut bien sͻr y avoir des exceptions, mais comme justement ce sont des
exceptions, on ne peut rien dire sans savoir en quoi ce sont des exceptions.
et en cas d'échec catastrophique, comment sait on par quels états on est
passés avant, qui nous ont conduits Í la catastrophe ?
mais, comment savoir si / en quoi ce sont des exceptions, si on n'a pas
l'énergie pour communiquer ?
et en cas d'échec catastrophique, comment sait on par quels états on est
passés avant, qui nous ont conduits Í la catastrophe ?
mais, comment savoir si / en quoi ce sont des exceptions, si on n'a pas
l'énergie pour communiquer ?
et en cas d'échec catastrophique, comment sait on par quels états on est
passés avant, qui nous ont conduits Í la catastrophe ?
mais, comment savoir si / en quoi ce sont des exceptions, si on n'a pas
l'énergie pour communiquer ?
Ca fait 25 ans que je n'ai plus écrit d'Ada.
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
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 ?
Dans mon optique, le monde Microsoft ne m'intéresse pas, donc je ne
vais pas trop élaborer.
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.
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.
Comme quoi faire du GUI *et* de la ligne de commande c'est compliqué.
- 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.
Ca fait 25 ans que je n'ai plus écrit d'Ada.
> 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
>> 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 ?
Dans mon optique, le monde Microsoft ne m'intéresse pas, donc je ne
vais pas trop élaborer.
> 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.
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.
Comme quoi faire du GUI *et* de la ligne de commande c'est compliqué.
> - 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.
Ca fait 25 ans que je n'ai plus écrit d'Ada.
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
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 ?
Dans mon optique, le monde Microsoft ne m'intéresse pas, donc je ne
vais pas trop élaborer.
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.
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.
Comme quoi faire du GUI *et* de la ligne de commande c'est compliqué.
- 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.
Thomas wrote:- une application desktop est un exécutable compilé pour la plateforme
qui l'exécute,
correct, sauf si c'est du bytecode ou du script (python, perl), lÍ il
n'y a pas de phase de compilation.
tandis qu'avec une application bureau client/serveur, il y a une part de
chaque coté, le serveur ne gère pas tout.
Et le client peut envoyer ses logs au serveur, ou pas.
est ce que le debug équivaut Í des "notifications normales", ou est ce
que c'est autre chose ?
Ah, le debug je l'activerais optionnellement et Í part.
stdout: informations normales (version du programme, opérations
normales)
stderr: erreurs, évt. debug.
quand il y a des msgs du genre "ignoring unknown switch" ou "Interactive
mode permits only one file on the command line",
comment les catégorises tu ? interaction utilisateur ou erreurs ?
erreurs.
On doit pouvoir faire
ton-programme 2>/dev/null
et n'avoir que des informations et aucun message d'erreur.
Thomas <fantome.forums.tDeContes@free.fr.invalid> wrote:
> - une application desktop est un exécutable compilé pour la plateforme
> qui l'exécute,
correct, sauf si c'est du bytecode ou du script (python, perl), lÍ il
n'y a pas de phase de compilation.
> tandis qu'avec une application bureau client/serveur, il y a une part de
> chaque coté, le serveur ne gère pas tout.
Et le client peut envoyer ses logs au serveur, ou pas.
> est ce que le debug équivaut Í des "notifications normales", ou est ce
> que c'est autre chose ?
Ah, le debug je l'activerais optionnellement et Í part.
stdout: informations normales (version du programme, opérations
normales)
stderr: erreurs, évt. debug.
> quand il y a des msgs du genre "ignoring unknown switch" ou "Interactive
> mode permits only one file on the command line",
> comment les catégorises tu ? interaction utilisateur ou erreurs ?
erreurs.
On doit pouvoir faire
ton-programme 2>/dev/null
et n'avoir que des informations et aucun message d'erreur.
Thomas wrote:- une application desktop est un exécutable compilé pour la plateforme
qui l'exécute,
correct, sauf si c'est du bytecode ou du script (python, perl), lÍ il
n'y a pas de phase de compilation.
tandis qu'avec une application bureau client/serveur, il y a une part de
chaque coté, le serveur ne gère pas tout.
Et le client peut envoyer ses logs au serveur, ou pas.
est ce que le debug équivaut Í des "notifications normales", ou est ce
que c'est autre chose ?
Ah, le debug je l'activerais optionnellement et Í part.
stdout: informations normales (version du programme, opérations
normales)
stderr: erreurs, évt. debug.
quand il y a des msgs du genre "ignoring unknown switch" ou "Interactive
mode permits only one file on the command line",
comment les catégorises tu ? interaction utilisateur ou erreurs ?
erreurs.
On doit pouvoir faire
ton-programme 2>/dev/null
et n'avoir que des informations et aucun message d'erreur.
tu as déjÍ programmé en Ada, et maintenant tu développes de l'embarqué
en C ?
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 ?
(sais tu si elles avaient de bonnes raisons de le faire ?)
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 ?
sauf que la partie cli aussi risque d'avoir besoin du fichier de config
(une suggestion ?)
ah oui, tu disais ça en lien avec le file-browser ?
je me demande ce qu'il peut y avoir comme pb quand par exemple 2
instances veulent modifier le même fichier ...
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 ?
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 ?
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.
donc par exemple : s'il y a un pb Í la lecture du fichier de config, je
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 ?
que me suggères tu Í cette étape ? :-)
tu as déjÍ programmé en Ada, et maintenant tu développes de l'embarqué
en C ?
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 ?
(sais tu si elles avaient de bonnes raisons de le faire ?)
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 ?
sauf que la partie cli aussi risque d'avoir besoin du fichier de config
(une suggestion ?)
ah oui, tu disais ça en lien avec le file-browser ?
je me demande ce qu'il peut y avoir comme pb quand par exemple 2
instances veulent modifier le même fichier ...
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 ?
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 ?
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.
donc par exemple : s'il y a un pb Í la lecture du fichier de config, je
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 ?
que me suggères tu Í cette étape ? :-)
tu as déjÍ programmé en Ada, et maintenant tu développes de l'embarqué
en C ?
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 ?
(sais tu si elles avaient de bonnes raisons de le faire ?)
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 ?
sauf que la partie cli aussi risque d'avoir besoin du fichier de config
(une suggestion ?)
ah oui, tu disais ça en lien avec le file-browser ?
je me demande ce qu'il peut y avoir comme pb quand par exemple 2
instances veulent modifier le même fichier ...
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 ?
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 ?
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.
donc par exemple : s'il y a un pb Í la lecture du fichier de config, je
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 ?
que me suggères tu Í cette étape ? :-)
le bytecode c'est le truc qu'on fait interpréter par les JVM ?
(dans ce cas lÍ il y a un peu de compilation quand même, puisque c'est
du code intermédiaire)
par contre, si c'est le logiciel lui-même qui doit envoyer ses logs au
serveur, je ne crois pas que ça puisse très bien marcher si c'est
l'intégrateur qui est chargé de gérer les fichiers !
Ah, le debug je l'activerais optionnellement et Í part.
oui, ça c'est déjÍ fait (mais si on l'active il faut bien que je le
traite).
(heu ... ça veut dire quoi "Í part" ?)
as tu des exemples d'opérations normales ?
(on était en mode graphique, lÍ )
quand tu dis "version du programme",
est-ce que tu parles seulement d'une option "--version",
ou bien est-ce que ça vaut aussi pour la version du programme qui est
affichée automatiquement quand on active le debug ?
j'ai oublié de te demander, mais je suppose que si on a un "usage: ..."
c'est pareil.
si on active le debug, est ce qu'on doit n'avoir aucun msg de debug,
mais avoir la version qui s'affiche en plus ?
le bytecode c'est le truc qu'on fait interpréter par les JVM ?
(dans ce cas lÍ il y a un peu de compilation quand même, puisque c'est
du code intermédiaire)
par contre, si c'est le logiciel lui-même qui doit envoyer ses logs au
serveur, je ne crois pas que ça puisse très bien marcher si c'est
l'intégrateur qui est chargé de gérer les fichiers !
Ah, le debug je l'activerais optionnellement et Í part.
oui, ça c'est déjÍ fait (mais si on l'active il faut bien que je le
traite).
(heu ... ça veut dire quoi "Í part" ?)
as tu des exemples d'opérations normales ?
(on était en mode graphique, lÍ )
quand tu dis "version du programme",
est-ce que tu parles seulement d'une option "--version",
ou bien est-ce que ça vaut aussi pour la version du programme qui est
affichée automatiquement quand on active le debug ?
j'ai oublié de te demander, mais je suppose que si on a un "usage: ..."
c'est pareil.
si on active le debug, est ce qu'on doit n'avoir aucun msg de debug,
mais avoir la version qui s'affiche en plus ?
le bytecode c'est le truc qu'on fait interpréter par les JVM ?
(dans ce cas lÍ il y a un peu de compilation quand même, puisque c'est
du code intermédiaire)
par contre, si c'est le logiciel lui-même qui doit envoyer ses logs au
serveur, je ne crois pas que ça puisse très bien marcher si c'est
l'intégrateur qui est chargé de gérer les fichiers !
Ah, le debug je l'activerais optionnellement et Í part.
oui, ça c'est déjÍ fait (mais si on l'active il faut bien que je le
traite).
(heu ... ça veut dire quoi "Í part" ?)
as tu des exemples d'opérations normales ?
(on était en mode graphique, lÍ )
quand tu dis "version du programme",
est-ce que tu parles seulement d'une option "--version",
ou bien est-ce que ça vaut aussi pour la version du programme qui est
affichée automatiquement quand on active le debug ?
j'ai oublié de te demander, mais je suppose que si on a un "usage: ..."
c'est pareil.
si on active le debug, est ce qu'on doit n'avoir aucun msg de debug,
mais avoir la version qui s'affiche en plus ?
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 ?
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 ?
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 ?
Typiquement, sous UNIX, il m'est arrivé de configurer des applications
de manière Í ce que le le log aille dans:
/network/fs.toto.ch/logs/$CLIENT/application-${UNIQUE}.log
et par la magie de l'automounter, les logs finissent sur le serveur
fs.toto.ch, dans le répertoire correspondant au nom du client, dans un
fichier correspondant au nom de l'application suffixée d'une valeur
unique contenant la date.
Evidemment, ça marche uniquement dans un réseau intégré ("domaine").
Autre technique que j'ai utilisée: quand le programme se termine, le log
est pushé sur le serveur par HTTPS.
Mais fais attention, tu poses des questions dans toutes les directions,
donc tu risques d'avoir des réponses dans toutes les directions.
Typiquement, sous UNIX, il m'est arrivé de configurer des applications
de manière Í ce que le le log aille dans:
/network/fs.toto.ch/logs/$CLIENT/application-${UNIQUE}.log
et par la magie de l'automounter, les logs finissent sur le serveur
fs.toto.ch, dans le répertoire correspondant au nom du client, dans un
fichier correspondant au nom de l'application suffixée d'une valeur
unique contenant la date.
Evidemment, ça marche uniquement dans un réseau intégré ("domaine").
Autre technique que j'ai utilisée: quand le programme se termine, le log
est pushé sur le serveur par HTTPS.
Mais fais attention, tu poses des questions dans toutes les directions,
donc tu risques d'avoir des réponses dans toutes les directions.
Typiquement, sous UNIX, il m'est arrivé de configurer des applications
de manière Í ce que le le log aille dans:
/network/fs.toto.ch/logs/$CLIENT/application-${UNIQUE}.log
et par la magie de l'automounter, les logs finissent sur le serveur
fs.toto.ch, dans le répertoire correspondant au nom du client, dans un
fichier correspondant au nom de l'application suffixée d'une valeur
unique contenant la date.
Evidemment, ça marche uniquement dans un réseau intégré ("domaine").
Autre technique que j'ai utilisée: quand le programme se termine, le log
est pushé sur le serveur par HTTPS.
Mais fais attention, tu poses des questions dans toutes les directions,
donc tu risques d'avoir des réponses dans toutes les directions.