gérer des fichiers log

Thomas

22/07/2021 à 17:12

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.)
--
RAPID maintainer
http://savannah.nongnu.org/projects/rapid/

Thomas

22/07/2021 à 20:41

In article <sd8fk9$8ac$,
Marc SCHAEFER wrote:

Thomas wrote:
si tu n'es pas développeur, tu ne peux pas l'inventer ...

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

ok, je comprend un peu mieux pourquoi les extensions n'ont pas
d'importance, et pourquoi il n'y a aucun pb Í passer le fichier de
config en ligne de commande :-)
quand on fait des applications graphiques, ce sont 2 choses qui ne sont
pas aussi simple.
mais je viens de réaliser que, pour ce domaine précis, tout simplement
je ne suis peut être pas sur le bon forum, pour trouver des gens un peu
dans le même univers.
que me conseillerais tu ?
fr.comp.applications.x11 ? fr.comp.applications.libres ?
Í chaque fois c'est un peu spécifique,
est ce qu'il y en a un qui serais suffisamment généraliste pour toutes
les applications graphiques ? (hors applications web : je parle des
applications installées sur son ordinateur et qui sont "Í portée de
clic")

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

Pour moi c'est assez interchangeable: une application peut aussi être
vue comme plusieurs logiciels (style: frontend HTML5/CSS, backend Perl
et bash).

ok
dans cette chose dont je suis le mainteneur, il y a principalement 2
choses :
- une application cliquable,
- une bibliothèque, qui est utilisée par l'application cliquable ainsi
que par toutes les applications qu'elle génère (et qui contient
notamment l'accès au "toolkit" graphique - sauf que ça peut en être un
autre que gtk).
je ne sais pas si c'est 1 logiciel constitué de ces 2 choses, ou 2
logiciels,
et je pense qu'il y a une application, mais je ne sais pas si c'est
l'application cliquable + la bibliothèque (qui permettent de compiler un
exécutable cliquable), ou seulement le morceau "application cliquable".

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

Oui, le wrapper en bash qui démarre ton application fait deux nouveaux
logs Í partir de stderr et de stdin, sauf si le log est tellement petit
que cela vaut la peine de l'ajouter.
en tant qu'usager, ça m'embête que les anciens fichiers de log soient
effacés Í chaque fois, je préfère pouvoir les relire au cas oÍ¹.

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

ça ne me dérange pas de préparer mon application pour faciliter la tache
d'un intégrateur, mais dans mon idée c'est l'intégrateur qui ferais le
wrapper, pas moi.
parallèlement Í ça, j'aime mieux que des fichiers de log soient générés
immédiatement, en plus de stdout et stderr,
autant pour moi, que pour un novice qui compilerais mon application Í
partir des sources, et Í qui j'aurais besoin de demander qu'il m'envoie
le log.
est ce que de ton point de vue, c'est Í moi de faire le wrapper ?

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

La pratique de pas mal de logiciels, c'est 1 fichier de backup du passé;
si tu veux plus, tu peux configurer des rsync régulier de données sur
ton poste (`time machine').
Je trouverais affreux que ton application génère des backups de backups
de backups sans possibilité de configurer ça! Mais par défaut, sans
configuration, 1 fichier de backup max peut convenir

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

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

ben non, justement, comme c'est ajouté Í la fin ça casse l'extension !
si l'application y est trop sensible, ça obligera Í modifier le nom du
fichier pour pouvoir l'ouvrir Í nouveau ...
y a t il une habitude, pour nommer les fichiers de backup ?
--
RAPID maintainer
http://savannah.nongnu.org/projects/rapid/

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

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

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

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

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

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

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

Pour moi c'est assez interchangeable: une application peut aussi être
vue comme plusieurs logiciels (style: frontend HTML5/CSS, backend Perl
et bash).

ok

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

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

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

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

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

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

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

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

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

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

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

Je trouverais affreux que ton application génère des backups de backups
de backups sans possibilité de configurer ça! Mais par défaut, sans
configuration, 1 fichier de backup max peut convenir

merci pour ton avis :-)

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

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

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

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

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

Vous avez filtré cet utilisateur ! Consultez son message

In article <sd8fk9$8ac$,
Marc SCHAEFER wrote:

Thomas wrote:
si tu n'es pas développeur, tu ne peux pas l'inventer ...

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

ok, je comprend un peu mieux pourquoi les extensions n'ont pas
d'importance, et pourquoi il n'y a aucun pb Í passer le fichier de
config en ligne de commande :-)
quand on fait des applications graphiques, ce sont 2 choses qui ne sont
pas aussi simple.
mais je viens de réaliser que, pour ce domaine précis, tout simplement
je ne suis peut être pas sur le bon forum, pour trouver des gens un peu
dans le même univers.
que me conseillerais tu ?
fr.comp.applications.x11 ? fr.comp.applications.libres ?
Í chaque fois c'est un peu spécifique,
est ce qu'il y en a un qui serais suffisamment généraliste pour toutes
les applications graphiques ? (hors applications web : je parle des
applications installées sur son ordinateur et qui sont "Í portée de
clic")

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

Pour moi c'est assez interchangeable: une application peut aussi être
vue comme plusieurs logiciels (style: frontend HTML5/CSS, backend Perl
et bash).

ok
dans cette chose dont je suis le mainteneur, il y a principalement 2
choses :
- une application cliquable,
- une bibliothèque, qui est utilisée par l'application cliquable ainsi
que par toutes les applications qu'elle génère (et qui contient
notamment l'accès au "toolkit" graphique - sauf que ça peut en être un
autre que gtk).
je ne sais pas si c'est 1 logiciel constitué de ces 2 choses, ou 2
logiciels,
et je pense qu'il y a une application, mais je ne sais pas si c'est
l'application cliquable + la bibliothèque (qui permettent de compiler un
exécutable cliquable), ou seulement le morceau "application cliquable".

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

Oui, le wrapper en bash qui démarre ton application fait deux nouveaux
logs Í partir de stderr et de stdin, sauf si le log est tellement petit
que cela vaut la peine de l'ajouter.
en tant qu'usager, ça m'embête que les anciens fichiers de log soient
effacés Í chaque fois, je préfère pouvoir les relire au cas oÍ¹.

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

ça ne me dérange pas de préparer mon application pour faciliter la tache
d'un intégrateur, mais dans mon idée c'est l'intégrateur qui ferais le
wrapper, pas moi.
parallèlement Í ça, j'aime mieux que des fichiers de log soient générés
immédiatement, en plus de stdout et stderr,
autant pour moi, que pour un novice qui compilerais mon application Í
partir des sources, et Í qui j'aurais besoin de demander qu'il m'envoie
le log.
est ce que de ton point de vue, c'est Í moi de faire le wrapper ?

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

La pratique de pas mal de logiciels, c'est 1 fichier de backup du passé;
si tu veux plus, tu peux configurer des rsync régulier de données sur
ton poste (`time machine').
Je trouverais affreux que ton application génère des backups de backups
de backups sans possibilité de configurer ça! Mais par défaut, sans
configuration, 1 fichier de backup max peut convenir

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

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

ben non, justement, comme c'est ajouté Í la fin ça casse l'extension !
si l'application y est trop sensible, ça obligera Í modifier le nom du
fichier pour pouvoir l'ouvrir Í nouveau ...
y a t il une habitude, pour nommer les fichiers de backup ?
--
RAPID maintainer
http://savannah.nongnu.org/projects/rapid/

Marc SCHAEFER

22/07/2021 à 20:58

Thomas wrote:

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

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

que me conseillerais tu ?

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

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

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

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

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

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

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

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

C'est tout Í fait envisageable.

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

Non, ceci serait de la duplication de travail par rapport Í écrire un
simple wrapper shell du genre:
#! /bin/bash
. ~/.config-APPLICATION/defines
log_prefix=APPLICATION-
log_postfix=.log
# alternatives: pas de nom d'application dans le nom
# de fichier log, car implicite, pas de postfix
# car inutile, les fichiers d'erreur et d'info
# s'appellent alors ... error et info
log_prefixlog_postfix
# conserver une copie de chaque type de log
for i in info error
do
[ -f $APPLICATION_LOG/$log_prefix{$i}$log_postfix ]
&& mv -f $APPLICATION_LOG/$log_prefix{$i}$log_postfix
$APPLICATION_LOG/$log_prefix{$i}$log_postfix.1
done
exec $APPLICATION_BIN/application
2> $APPLICATION_LOG/${log_prefix}error$log_postfix

$APPLICATION_LOG/${log_prefix}info$log_postfix

Avec dans ~/.config-APPLICATION/defines
APPLICATION_PREFIX=<point d'installation, Í adapter Í l'installation>
APPLICATION_LOG=$APPLICATION_PREFIX/logs
APPLICATION_BIN=$APPLICATION_PREFIX/bin

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

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

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

C'était exprès. En tant qu'utilisateur, je ne veux pas qu'il soit trop
facile de se tromper entre un original et une vieille copie.
Il faut choisir le bon backup, et le renommer pour y accéder, cela me
semble une excellente chose Í faire pour éviter la confusion.
Ou, clic-droit, ouvrir avec ...

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

Si ton application plante tellement souvent qu'il est une opération très
courante de devoir accéder aux backups et pas aux originaux, alors une
alternative est:
fichier.gui -> fichier-backup.gui
mais c'est terriblement moche, je trouve, et on risque de confondre avec
l'original.
Après, je ne suis pas du tout un utilisateur Microsoft courant, donc je
ne pense certainement pas comme 95% des gens.

Thomas <fantome.forums.tDeContes@free.fr.invalid> wrote:

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

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

que me conseillerais tu ?

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

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

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

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

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

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

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

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

C'est tout Í fait envisageable.

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

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

#! /bin/bash

. ~/.config-APPLICATION/defines

log_prefix=APPLICATION-
log_postfix=.log

# alternatives: pas de nom d'application dans le nom
# de fichier log, car implicite, pas de postfix
# car inutile, les fichiers d'erreur et d'info
# s'appellent alors ... error et info
log_prefixlog_postfix
# conserver une copie de chaque type de log
for i in info error
do
[ -f $APPLICATION_LOG/$log_prefix{$i}$log_postfix ]
&& mv -f $APPLICATION_LOG/$log_prefix{$i}$log_postfix
$APPLICATION_LOG/$log_prefix{$i}$log_postfix.1
done

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

$APPLICATION_LOG/${log_prefix}info$log_postfix

Avec dans ~/.config-APPLICATION/defines

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

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

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

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

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

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

Ou, clic-droit, ouvrir avec ...

si l'application y est trop sensible, ça obligera Í modifier le nom du
fichier pour pouvoir l'ouvrir Í nouveau ...

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

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

fichier.gui -> fichier-backup.gui

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

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

Vous avez filtré cet utilisateur ! Consultez son message

Thomas wrote:

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

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

que me conseillerais tu ?

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

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

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

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

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

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

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

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

C'est tout Í fait envisageable.

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

Non, ceci serait de la duplication de travail par rapport Í écrire un
simple wrapper shell du genre:
#! /bin/bash
. ~/.config-APPLICATION/defines
log_prefix=APPLICATION-
log_postfix=.log
# alternatives: pas de nom d'application dans le nom
# de fichier log, car implicite, pas de postfix
# car inutile, les fichiers d'erreur et d'info
# s'appellent alors ... error et info
log_prefixlog_postfix
# conserver une copie de chaque type de log
for i in info error
do
[ -f $APPLICATION_LOG/$log_prefix{$i}$log_postfix ]
&& mv -f $APPLICATION_LOG/$log_prefix{$i}$log_postfix
$APPLICATION_LOG/$log_prefix{$i}$log_postfix.1
done
exec $APPLICATION_BIN/application
2> $APPLICATION_LOG/${log_prefix}error$log_postfix

$APPLICATION_LOG/${log_prefix}info$log_postfix

Avec dans ~/.config-APPLICATION/defines
APPLICATION_PREFIX=<point d'installation, Í adapter Í l'installation>
APPLICATION_LOG=$APPLICATION_PREFIX/logs
APPLICATION_BIN=$APPLICATION_PREFIX/bin

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

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

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

C'était exprès. En tant qu'utilisateur, je ne veux pas qu'il soit trop
facile de se tromper entre un original et une vieille copie.
Il faut choisir le bon backup, et le renommer pour y accéder, cela me
semble une excellente chose Í faire pour éviter la confusion.
Ou, clic-droit, ouvrir avec ...

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

Si ton application plante tellement souvent qu'il est une opération très
courante de devoir accéder aux backups et pas aux originaux, alors une
alternative est:
fichier.gui -> fichier-backup.gui
mais c'est terriblement moche, je trouve, et on risque de confondre avec
l'original.
Après, je ne suis pas du tout un utilisateur Microsoft courant, donc je
ne pense certainement pas comme 95% des gens.

Stephane Tougard

22/07/2021 à 21:25

On 2021-07-22, Marc SCHAEFER wrote:

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

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

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

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

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

Le gros problème de la gestion des fichiers de logs est la rotation de
ces mêmes fichiers. Face Í ce problème, il y a plusieurs solutions :
- Envoyer les logs sur STDERR (pas STDOUT qui n'est pas fait pour ça)
et laisser l'admin ou le wrapper le gérer (avec logger par exemple).
- Gérer ses propres file descriptors, dans ce cas il faut gérer un
signal pour fermer et ré-ouvrir les FD après rotation des logs
- S'en fiche (ce que font 99% des applications graphiques).

Thomas

23/07/2021 à 01:58

In article <sd8faa$8ac$,
Marc SCHAEFER wrote:

Thomas 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
:/tmp/tt$ bin/bla
terminal 2:
# pendant l'exécution, je change la structure des répertoires
:/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 :
(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/

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/

Vous avez filtré cet utilisateur ! Consultez son message

In article <sd8faa$8ac$,
Marc SCHAEFER wrote:

Thomas 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
:/tmp/tt$ bin/bla
terminal 2:
# pendant l'exécution, je change la structure des répertoires
:/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 :
(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/

Thomas

23/07/2021 à 02:32

In article <sdcf46$glq$,
Marc SCHAEFER wrote:

Thomas wrote:
que me conseillerais tu ?

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

il me semble que la seule chose que ça fait en plus c'est générer des
fichiers de code, correspondant aux fichiers d'interfaces graphiques
édités (comme Glade).
mais peut être as tu besoin d'autres détails ?

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

saurais tu définir ce que c'est qu'un core, précisément ?
(je devine, mais le risque de malentendu est élevé, alors ... autant
prévenir ;-) )

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

Non, ceci serait de la duplication de travail par rapport Í écrire un
simple wrapper shell du genre:
#! /bin/bash

merci bcp pour l'exemple :-)

. ~/.config-APPLICATION/defines

si j'ai bien compris, ça me donne l'avantage de pouvoir rester
intégralement dans le répertoire de compilation (par ex pour tous ceux
qui compilent Í partir des sources),
et pour un intégrateur, ça sera très facile de changer tout ça comme il
veut, alors qu'au contraire ça serais très difficile pour lui de
modifier du code source ?

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

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

ça génère qques inconvénients supplémentaires, notamment pour la
portabilité :
par exemple, si un novice qui compilerais mon application Í partir des
sources, sous windows, me dit :
- que ça ne marche pas,
- que quand il clique sur le wrapper, ça lui ouvre le script dans un
éditeur de texte,
- que quand il clique sur l'exécutable, ça ne lui affiche aucune fenêtre
"shell" (je ne sais plus comment ils appellent ça sous windows), donc il
ne sait pas comment afficher les erreurs
Í ce moment lÍ , qu'est ce que je fais, moi ? :-D

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

C'était exprès. En tant qu'utilisateur, je ne veux pas qu'il soit trop
facile de se tromper entre un original et une vieille copie.
Il faut choisir le bon backup, et le renommer pour y accéder, cela me
semble une excellente chose Í faire pour éviter la confusion.

bon argument :-)

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

c'est pas qqch Í base de '~' ?
ou alors ça n'est que sous windows, que les gens font ça ?

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

je vais tacher d'arranger ça ;-)
en attendant, j'ai besoin d'un minimum pour mon confort dans le travail,
et en même temps j'essaye de faire le moins possible de choses qui
embêtent les autres :-)
--
RAPID maintainer
http://savannah.nongnu.org/projects/rapid/

In article <sdcf46$glq$1@shakotay.alphanet.ch>,
Marc SCHAEFER <schaefer@alphanet.ch> wrote:

Thomas <fantome.forums.tDeContes@free.fr.invalid> wrote:

> que me conseillerais tu ?

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

il me semble que la seule chose que ça fait en plus c'est générer des
fichiers de code, correspondant aux fichiers d'interfaces graphiques
édités (comme Glade).

mais peut être as tu besoin d'autres détails ?

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

saurais tu définir ce que c'est qu'un core, précisément ?
(je devine, mais le risque de malentendu est élevé, alors ... autant
prévenir ;-) )

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

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

#! /bin/bash

merci bcp pour l'exemple :-)

. ~/.config-APPLICATION/defines

si j'ai bien compris, ça me donne l'avantage de pouvoir rester
intégralement dans le répertoire de compilation (par ex pour tous ceux
qui compilent Í partir des sources),
et pour un intégrateur, ça sera très facile de changer tout ça comme il
veut, alors qu'au contraire ça serais très difficile pour lui de
modifier du code source ?

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

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

ça génère qques inconvénients supplémentaires, notamment pour la
portabilité :

par exemple, si un novice qui compilerais mon application Í partir des
sources, sous windows, me dit :
- que ça ne marche pas,
- que quand il clique sur le wrapper, ça lui ouvre le script dans un
éditeur de texte,
- que quand il clique sur l'exécutable, ça ne lui affiche aucune fenêtre
"shell" (je ne sais plus comment ils appellent ça sous windows), donc il
ne sait pas comment afficher les erreurs

Í ce moment lÍ , qu'est ce que je fais, moi ? :-D

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

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

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

bon argument :-)

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

c'est pas qqch Í base de '~' ?
ou alors ça n'est que sous windows, que les gens font ça ?

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

je vais tacher d'arranger ça ;-)

en attendant, j'ai besoin d'un minimum pour mon confort dans le travail,
et en même temps j'essaye de faire le moins possible de choses qui
embêtent les autres :-)

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

Vous avez filtré cet utilisateur ! Consultez son message

In article <sdcf46$glq$,
Marc SCHAEFER wrote:

Thomas wrote:
que me conseillerais tu ?

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

il me semble que la seule chose que ça fait en plus c'est générer des
fichiers de code, correspondant aux fichiers d'interfaces graphiques
édités (comme Glade).
mais peut être as tu besoin d'autres détails ?

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

saurais tu définir ce que c'est qu'un core, précisément ?
(je devine, mais le risque de malentendu est élevé, alors ... autant
prévenir ;-) )

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

Non, ceci serait de la duplication de travail par rapport Í écrire un
simple wrapper shell du genre:
#! /bin/bash

merci bcp pour l'exemple :-)

. ~/.config-APPLICATION/defines

si j'ai bien compris, ça me donne l'avantage de pouvoir rester
intégralement dans le répertoire de compilation (par ex pour tous ceux
qui compilent Í partir des sources),
et pour un intégrateur, ça sera très facile de changer tout ça comme il
veut, alors qu'au contraire ça serais très difficile pour lui de
modifier du code source ?

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

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

ça génère qques inconvénients supplémentaires, notamment pour la
portabilité :
par exemple, si un novice qui compilerais mon application Í partir des
sources, sous windows, me dit :
- que ça ne marche pas,
- que quand il clique sur le wrapper, ça lui ouvre le script dans un
éditeur de texte,
- que quand il clique sur l'exécutable, ça ne lui affiche aucune fenêtre
"shell" (je ne sais plus comment ils appellent ça sous windows), donc il
ne sait pas comment afficher les erreurs
Í ce moment lÍ , qu'est ce que je fais, moi ? :-D

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

C'était exprès. En tant qu'utilisateur, je ne veux pas qu'il soit trop
facile de se tromper entre un original et une vieille copie.
Il faut choisir le bon backup, et le renommer pour y accéder, cela me
semble une excellente chose Í faire pour éviter la confusion.

bon argument :-)

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

c'est pas qqch Í base de '~' ?
ou alors ça n'est que sous windows, que les gens font ça ?

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

je vais tacher d'arranger ça ;-)
en attendant, j'ai besoin d'un minimum pour mon confort dans le travail,
et en même temps j'essaye de faire le moins possible de choses qui
embêtent les autres :-)
--
RAPID maintainer
http://savannah.nongnu.org/projects/rapid/

Thomas

23/07/2021 à 03:03

In article <sdcgo6$k10$,
Stephane Tougard wrote:

On 2021-07-22, Marc SCHAEFER wrote:
Une application web n'est-elle pas une application graphique?

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

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

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

est ce que ça te dirais de jeter un oeil Í ce msg stp ?
si je l'ai bien compris, Marc répond "oui" aux 3 questions.

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

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

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

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

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

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

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

veux tu dire qu'elles produisent quand même des logs, mais qu'elles s'en
fichent d'écraser les logs précédents ou d'en avoir qui montent jusqu'Í
l'infini ?
--
RAPID maintainer
http://savannah.nongnu.org/projects/rapid/

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

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

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

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

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

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

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

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

Face Í ce problème, il y a plusieurs solutions :

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

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

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

peux tu préciser stp ?

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

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

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

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

Vous avez filtré cet utilisateur ! Consultez son message

Stephane Tougard

23/07/2021 à 06:03

On 2021-07-05, Thomas wrote:

est ce que c'est qqch de plus ou moins normalisé, ou est ce qu'on fait
vraiment ce qu'on veut ?

Par définition, on fait ce qu'on veut. Il y a des "good practices",
mais ...

1
j'aime bcp l'idée d'avoir un n° que je peux incrementer jusqu'Í
l'infini, pas de limite supérieure :-)

file-20210723.log
Ou le fichier de log porte la date du jour, j'ai déjÍ vu ça sur des
logiciels serveurs qui gèrent eux mêmes leurs logs.

2
le gros pb, c'est que ça ajoute le n° après l'extension plutÍ´t qu'avant.
du coup, mon éditeur de texte croit avoir affaire Í des pages de man
plutÍ´t qu'Í des logs !
quel genre de pb ça peut poser si je décide de faire différemment ?
et pendant que j'y suis, pourquoi ne pas corriger ça au niveau du
système ?

Tu mets la date ou le numéro ou tu veux, c'est toi qui écrit le
code. Attention aux droits, Í moins que ton programme runs en root, il
n'a pas le droit d'écrire dans /var/log
Tu peux utiliser syslog pour ça et le laisser gérer.

si Í la place je met juste le dernier n° (le 1er dispo) au fichier qui
n'en a pas encore, sans toucher aux autres, qu'est ce que vous en dites ?

Sans savoir ce qu'est l'application, ce qu'elle fait. C'est difficile
de répondre Í une telle question.

Stephane Tougard

23/07/2021 à 06:07

On 2021-07-23, Thomas wrote:

- est ce que tu considères que l'application peut gérer un historique de
fichiers de logs, comme logrotate,

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

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

Non.

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

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

(et STDOUT est fait pour quoi ?)

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

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

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

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

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

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

Marc SCHAEFER

23/07/2021 à 08:41

Thomas 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=valeur1n
cle2=valeur2n
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.

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=valeur1n
cle2=valeur2n

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.

Vous avez filtré cet utilisateur ! Consultez son message

Thomas 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=valeur1n
cle2=valeur2n
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.

gérer des fichiers log

10 réponses

Veuillez sélectionner un problème