Re: gérer des fichiers log

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

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

POSIX, oui. Ca fait 25 ans que je n'ai plus écrit d'Ada.

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

Voilà.

et si on supprime ce répertoire, qu'est ce que ça donne ?

Le répertoire n'est plus accessible avec son nom, mais reste accessible
à tous ceux qui ont encore son handle, avec quelques bizarreries:

schaefer@reliand:~$ mkdir /tmp/tt
schaefer@reliand:~$ cd /tmp/tt
schaefer@reliand:/tmp/tt$ rmdir /tmp/tt
schaefer@reliand:/tmp/tt$ ls
schaefer@reliand:/tmp/tt$ touch abcd
touch: cannot touch 'abcd': No such file or directory
schaefer@reliand:/tmp/tt$ ls -la
total 0
schaefer@reliand:/tmp/tt$ pwd
/tmp/tt
schaefer@reliand:/tmp/tt$ /bin/pwd
/bin/pwd: couldn't find directory entry in '..' with matching i-node

bon, a priori, je n'ai pas besoin de pousser la résilience de mon
logiciel au point où on puisse le changer de place pendant son
exécution,

C'était pour te faire comprendre la philosophie complètement différente
de UNIX concernant les chemins.  Il n'est en général pas une bonne
pratique de `deviner' où est "son" répertoire.  Soit c'est en dur
(/etc/application/), ~/.application, etc), soit c'est une variable
d'environnement, soit c'est configuré quelque part.

Et changer le répertoire courant durant l'exécution, c'est changer
la référence et donc on a des soucis pour tous les arguments de ligne de
commande qui sont en fait des fichiers exprimés relativement (au
répertoire courant au moment du lancement).

le Filesystem Hierarchy Standard (même s'il devient apparemment
obsolète).

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

https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard

Apparemment c'est surtout que certaines distributions ont laissé tombé.

et là le rangement en sous-répertoires retrouve tout son intérêt pour
la commodité.

C'est juste.

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

Dommage, j'adore quand je peux générer ce genre de fichier
automatiquement, par exemple pour préconfigurer une salle de machines
ou tester des applications automatiquement.

Donc: configuration stocké en format texte, dans
~/.config/application/config par exemple.

Quel format texte?  Totalement égal si je peux le générer avec un
template.

j'ai cru comprendre que pour permettre aux utilisateurs de Windows de
double cliquer sur un fichier pour l'ouvrir, il est nécessaire de

Microsoft est pour moi hors sujet.

prendre en charge l'indication du fichier cliqué comme argument unique
(je ne sais pas comment ça se passe sur les autres plateformes)

La plupart du temps le GUI va simplement lancer /usr/bin/toto
nom-fichier-double-cliqué. Toutefois, la plupart des GUI permettent de
configurer le comportement avec des templates (exemple: programme %f
dans l'association MIME), il me semble.

donc, comment faire qqch qui réponde à ton besoin et qui soit compatible
avec ce comportement de Windows ?

Si tu veux faire une application multi-plateforme, tu peux corriger les
problèmes Microsoft soit dans ton application, soit simplement, et cela
serait mon approche, livrer un wrapper (sous forme batch Microsoft ou
autre) qui corrige les problèmes de compatibilité de cette plateforme ?

Dans mon optique, le monde Microsoft ne m'intéresse pas, donc je ne
vais pas trop élaborer.

D'autant plus qu'on peut facilement tourner du Linux sur Microsoft
aujourd'hui, y compris bientôt en mode graphique.

dans quels cas on peut vouloir exprimer un chemin relativement depuis un
autre répertoire ?

C'était lié à ton file-browser qui change de répertoire courant. Le
comportement recommandé est de ne pas changer de répertoire courant,
pour que les noms de fichiers exprimés relativement en ligne de commande
soient toujours ouverts au bon endroit sans devoir y préfixer le
répertoire courant au moment du lancement du programme.

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

Soit relatif au répertoire courant, soit absolu, à choix.

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

 
ok pour celui là,

Sous forme de handle de préférence, car sous forme de chemin -> on
revient au problème que le chemin est moins fort pour identifier que le
handle.

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

Aucune idée :)

Je constate aussi qu'il y a un problème inhérent aux GUI ou plutôt aux
applications qui n'acceptent pas d'être lancées deux fois.

Exemple: je lance deux fois loffice dans deux répertoires différents. La
construction même de loffice fait que le deuxième lancement ouvre en
fait une deuxième fenêtre dans le 1er programme, avec l'environnement
d'exécution du 1er programme (y.c. son répertoire courant).

Pour moi, c'est un bug, mais c'est à quoi s'attendent les utilisateurs
Microsoft et Apple.

Comme quoi faire du GUI *et* de la ligne de commande c'est compliqué.

gnumeric sous UNIX/X11 par exemple a le comportement auquel je
m'attends, mais pas libreoffice.

- parce que je ne sens pas la prise en charge d'un wrapper script qui va
marcher à tous les coups sur toutes les plateformes
(voir l'autre branche du fil)

Un script pour chaque plateforme, plutôt.

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

Du point de vue de ton application, il est possible que l'écriture dans
ces fichiers retourne une erreur, oui. A toi de la traiter (p.ex. en
l'ignorant ou en la reportant au niveau supérieur: exemple: erreur
d'écriture dans stdout -> warning unique dans stderr).

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

Erreur d'écriture dans fichier de log -> erreur dans stderr et dialogue
graphique vu que c'est quand même quelque chose de rare.