Re: gérer des fichiers log

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

   - si tu le mémorises sous forme d'un handle de répertoire ouvert,
     parfait

je n'ai pas entendu dire qu'on pouvait faire ça en ada,
ça doit être une fonction spécifique UNIX ?

 
   - si tu le mémorises sous forme de chemin, alors tu as le même
     risque si quelqu'un modifie l'arborescence
 
Ce problème ne se pose pas si on ne change pas le répertoire courant.
 
Et si tu génères uniquement des logs dans stdout et stderr, le besoin du
répertoire courant est inutile, sauf si tu charges des fichiers
relativement à lui (ce qui me semble une bonne pratique), mais alors il
n'y a rien à faire: juste ouvrir les fichiers (config p.ex.) avec le
chemin indiqué par l'utilisateur (relatif ou absolu).

si je te comprend bien, l'avantage de se référer au répertoire courant,
sans le mémoriser ni le changer, c'est qu'il supporte les renommages en
cours d'exécution ?
et si on supprime ce répertoire, qu'est ce que ça donne ?


(sujet connexe)
bon, a priori, je n'ai pas besoin de pousser la résilience de mon
logiciel au point où on puisse le changer de place pendant son
exécution,
ça me parait raisonnable de demander à l'utilisateur de le fermer pour
faire ça.

(je comprend tout à fait que ça puisse être un besoin pour les serveurs,
par exemple)

Donc KISS: ne pas changer le répertoire courant.

j'étais de ton avis donc tu n'as pas tellement eu à me convaincre,
donc je vais virer tout ça et gérer les chemins autrement :-)

 

~/.<nom-application>/
plutôt que
~/.config/<nom-application>/

 
Les deux existent, le ~/.config est une convention plutôt récente des
GUI comme GNOME ou kde, me semble-t-il.

ah, tant mieux !
alors j'invite tous les developpeurs qui me lisent à préférer
~/.config/<nom-application>/ pour ranger leurs données :-)

Mais le mieux est de consulter
le Filesystem Hierarchy Standard (même s'il devient apparemment
obsolète).

qu'est ce que c'est ?
(il a peut être besoin d'une mise à jour ?)

 

perso, je n'aime pas me retrouver avec une quantité astronomique de ~/.*
:-(

 
Ca ne gêne pas sous UNIX, ce sont des fichiers cachés

"tant mieux" pour la vie de tous les jours,

sauf que de temps en temps on a besoin de les afficher quand même,
autant en interface graphique qu'en ligne de commande.
et là le rangement en sous-répertoires retrouve tout son intérêt pour la
commodité.

j'aimerais bcp mieux que tout ça soit rangé dans un répertoire, mais
pour ça il faut que bcp de développeurs se mettent d'accord ..... !
 
(`~/.config/` ? `~/.hidden-data/` ?)

 
Alternative: ne pas imposer ce choix à l'utilisateur, mais passer le nom
du fichier de config en argument, éventuellement avec une
préconfiguration classique dans le wrapper.

(voir plus bas)

aurais tu des tuyaux à me donner, pour lire un fichier de configuration
d'une manière qui soit à la fois suffisamment fiable et pas trop
casse-pied à programmer ?

en fait, je pense que j'aurai l'occasion de faire une fenêtre de
"préférences", qui va éditer "en mode graphique" un fichier de ce genre
(donc ce fichier sera écrit et lu symétriquement, et pas édité à la
main).

Par contre, ça ne résout pas le pb de la localisation de ce fichier ...

tu veux dire que tu trouves acceptable que ça soit le comportement par
défaut, mais que tu veux pouvoir le modifier par la ligne de commande,
c'est ça ?

 
oui, ou le fichier de config *doit* être spécifié systématiquement en
ligne de commande; les deux me vont car dans le 2e cas ... on peut faire
un wrapper pour réduire au 1er cas.

j'ai cru comprendre que pour permettre aux utilisateurs de Windows de
double cliquer sur un fichier pour l'ouvrir, il est nécessaire de
prendre en charge l'indication du fichier cliqué comme argument unique
(je ne sais pas comment ça se passe sur les autres plateformes)

donc, comment faire qqch qui réponde à ton besoin et qui soit compatible
avec ce comportement de Windows ?
(en essayant d'éviter des galipettes du genre : lire le fichier pour
savoir si c'est un fichier de config ou un document utilisateur)

(voir l'autre branche du fil)

 

en fait, a priori j'étais comme toi, je trouvais ça saugrenu qu'un
logiciel autre qu'un shell modifie son répertoire courant (et je me
demande pourquoi l'API Ada nous donne cette possibilité)

 
sémantiquement, tu vas changer de répertoire à chaque fois que tu veux
relativement exprimer un chemin depuis ce répertoire, mais il faut faire
attention à bien faire ce que l'utilisateur s'attend.

dans quels cas on peut vouloir exprimer un chemin relativement depuis un
autre répertoire ?
(voir plus bas)

- soit on considère que c'est équivalent à une application CLI à qui on
passe le nom du fichier comme argument, avec un chemin
- soit on considère que c'est équivalent à un shell dans lequel on fait
des `cd`, et à la fin on passe le nom du fichier comme argument, sans
chemin
 
je crois que toi et moi on est tous les 2 sur la 1ere alternative,
mais je devine que le mainteneur précédent (ou le précédent encore) qui
a programmé ça était sur la 2eme :-)
 
un avis là dessus ?

 
Il me semblerait logique que le répertoire courant dans lequel on a
démarré l'application (en shell ou en GUI) soit le premier présenté par
la boîte de sélection, et ensuite il me semblerait logique que la boîte
de sélection retourne le chemin relatif depuis ce répertoire courant du
fichier sélectionné, ou le chemin absolu si la personne a choisi
d'entrer un chemin absolu ou a cliqué sur autre chose que le répertoire
courant.

ok, quand on change de répertoire, on bascule en "tout en chemins
absolus" pour designer les fichiers voulus, mais on ne touche pas au
répertoire courant.

 

si une application graphique ne devrais /jamais/ changer de répertoire
courant,
- est ce que c'est un domaine strictement réservé aux shells,
- ou est ce qu'il y a d'autres cas de figure où c'est approprié qu'un
logiciel le fasse ?

 
Je pense qu'une application quelconque a plein de raison de changer de
répertoire courant (p.ex. lancer un logiciel complémentaire dans son
environnement propre),

ah oui, ça pourrais m'arriver plus tard :-)
(mais Il me semble que je pourrais aussi donner tous les paramètres en
chemins absolus)

mais elle peut sauvegarder le répertoire
précédent et y revenir

ok pour celui là,

y a-t-il d'autres exemples ? pour la curiosité :-)

 

disons que, quelle que soit la méthode utilisée par l'application pour
définir un chemin dont elle aura besoin au cours de sa vie, changer la
structure des répertoires pendant qu'elle tourne est risqué :
j'ai entendu dire que la pratique est de lire le fichier de config au
démarrage, mais pas de vérifier régulièrement s'il a été modifié.

 
C'est juste: il ne faudrait changer aucun des chemins absolus qui
figureraient dans la config. Par contre, si tout est exprimé
relativement au répertoire courant, le risque n'existe pas.

il ne faudrait changer aucun des chemins qui figureraient dans la config.
y compris la partie écrite des chemins relatifs.
Par contre, si je t'ai bien compris, on peut changer le chemin du
répertoire courant parce qu'il est "mémorisé sous forme de handle" (ou
équivalent)

 

Je ne sais pas, je ne sais toujours pas pourquoi ton programme a besoin
de créer des fichiers de logs plutôt que d'utiliser stdout et stderr,

 
en plus, pas à la place.

 
Ah, des logs supplémentaires?   Pourquoi?

- parce que je ne sens pas la prise en charge d'un wrapper script qui va
marcher à tous les coups sur toutes les plateformes
(voir l'autre branche du fil)
- pour, à la fois, te contenter avec les sorties standards, et me
contenter avec des fichiers écrits immédiatement

Comment?  Combien?

ça dépend comment on compte, mais en gros, chaque msg à logger est
dupliqué (voire * 3 avec l'interface graphique).

 

c'est pour ça qu'il est imaginable d'ignorer les erreurs d'écriture 
quand il y en a, considérant que c'est rattrapable via stdout et stderr
(mais en fait c'est ce que j'avais écrit juste avant, non ?)

 
Je ne comprends pas ce que tu entends par erreur d'écriture et en
particulier avec stdout et stderr.

si je te comprend bien, écrire sur stdout et stderr ne provoque jamais
aucune erreur d'aucune sorte ? le pire qui puisse arriver, c'est que ce
qu'on y envoie tombe dans un puits sans fond ?


quand je reçois un msg à traiter, j'ai 3 interfaces à ma disposition :
- les sorties standards
- les fichiers de logs
- l'interface graphique

ce dont je parlais était d'ignorer les erreurs d'écriture dans les
fichiers de logs, puisque les sorties standards suffisent pour récupérer
l'information.

cad de ne pas indiquer sur les sorties standards et dans l'interface
graphique, qu'on a eu une erreur au moment d'écrire dans les fichiers de
logs.

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