j'ai des logs Í gérer, et j'aimerais mieux ne pas les effacer quand j'ai
besoin de place pour un nouveau fichier.
j'ai regardé ce qui se passe dans /var/log/ :
est ce que c'est qqch de plus ou moins normalisé, ou est ce qu'on fait
vraiment ce qu'on veut ?
1
j'aime bcp l'idée d'avoir un n° que je peux incrementer jusqu'Í
l'infini, pas de limite supérieure :-)
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 ?
3
apparemment, quand on a besoin de place, on décale tous les fichiers
d'un cran.
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 ?
dans les 2 cas, chercher le 1er point ne marche pas, et le dernier non plus :-(
Quel est l'objectif?
je crois que j'ai trouvé comment résumer la situation : depuis le début je parle depuis mon point de vue de développeur, mais Nicolas et toi ne l'aviez pas compris Nicolas me suggérais par ex d'utiliser un "timestamp" Í la seconde, plutÍ´t qu'un "timestamp" au jour + un n° incrémental, ce qui est tout Í fait applicable depuis mon point de vue de développeur pour les fichiers de logs que mon logiciel gère lui même (voir qu. 3 du msg ) alors j'envisageais d'ajouter ça juste avant le ".log", plutÍ´t qu'après comme fait logrotate. et puis j'ai eu l'idée de faire cette branche de la discussion :
question sur les extensions, pour le cas o͹ je généraliserais cette procédure pour "pousser Í coté" un fichier existant :
ça me permettrais d'appliquer cette procédure Í tout type de fichier que mon logiciel aurais envie de créer, s'apercevant qu'un fichier de meme nom existe deja.
tandis que moi, en fait ce que je veux, c'est concatener qqch au nom de base, sans casser d'extension imbriquée qq soit leur nombre.
le pb est de pouvoir faire une telle procédure dans une bibliothèque, ce qui implique que cette procédure ne connaitra pas d'avance les extensions des fichiers qu'on va lui demander de "pousser Í coté". -- RAPID maintainer http://savannah.nongnu.org/projects/rapid/
In article <sd0lb2$b4m$2@shakotay.alphanet.ch>,
Marc SCHAEFER <schaefer@alphanet.ch> wrote:
Thomas <fantome.forums.tDeContes@free.fr.invalid> wrote:
> dans les 2 cas, chercher le 1er point ne marche pas, et le dernier non
> plus :-(
Quel est l'objectif?
je crois que j'ai trouvé comment résumer la situation :
depuis le début je parle depuis mon point de vue de développeur, mais
Nicolas et toi ne l'aviez pas compris
Nicolas me suggérais par ex d'utiliser un "timestamp" Í la seconde,
plutÍ´t qu'un "timestamp" au jour + un n° incrémental,
ce qui est tout Í fait applicable depuis mon point de vue de développeur
pour les fichiers de logs que mon logiciel gère lui même (voir qu. 3 du
msg <fantome.forums.tDeContes-BC1C13.00324017072021@news.free.fr> )
alors j'envisageais d'ajouter ça juste avant le ".log", plutÍ´t qu'après
comme fait logrotate.
et puis j'ai eu l'idée de faire cette branche de la discussion :
question sur les extensions, pour le cas o͹ je généraliserais cette
procédure pour "pousser Í coté" un fichier existant :
ça me permettrais d'appliquer cette procédure Í tout type de fichier que
mon logiciel aurais envie de créer, s'apercevant qu'un fichier de meme
nom existe deja.
tandis que moi, en fait ce que je veux, c'est concatener qqch au nom de
base, sans casser d'extension imbriquée qq soit leur nombre.
le pb est de pouvoir faire une telle procédure dans une bibliothèque, ce
qui implique que cette procédure ne connaitra pas d'avance les
extensions des fichiers qu'on va lui demander de "pousser Í coté".
dans les 2 cas, chercher le 1er point ne marche pas, et le dernier non plus :-(
Quel est l'objectif?
je crois que j'ai trouvé comment résumer la situation : depuis le début je parle depuis mon point de vue de développeur, mais Nicolas et toi ne l'aviez pas compris Nicolas me suggérais par ex d'utiliser un "timestamp" Í la seconde, plutÍ´t qu'un "timestamp" au jour + un n° incrémental, ce qui est tout Í fait applicable depuis mon point de vue de développeur pour les fichiers de logs que mon logiciel gère lui même (voir qu. 3 du msg ) alors j'envisageais d'ajouter ça juste avant le ".log", plutÍ´t qu'après comme fait logrotate. et puis j'ai eu l'idée de faire cette branche de la discussion :
question sur les extensions, pour le cas o͹ je généraliserais cette procédure pour "pousser Í coté" un fichier existant :
ça me permettrais d'appliquer cette procédure Í tout type de fichier que mon logiciel aurais envie de créer, s'apercevant qu'un fichier de meme nom existe deja.
tandis que moi, en fait ce que je veux, c'est concatener qqch au nom de base, sans casser d'extension imbriquée qq soit leur nombre.
le pb est de pouvoir faire une telle procédure dans une bibliothèque, ce qui implique que cette procédure ne connaitra pas d'avance les extensions des fichiers qu'on va lui demander de "pousser Í coté". -- RAPID maintainer http://savannah.nongnu.org/projects/rapid/
Marc SCHAEFER
Thomas wrote:
le pb est de pouvoir faire une telle procédure dans une bibliothèque, ce qui implique que cette procédure ne connaitra pas d'avance les extensions des fichiers qu'on va lui demander de "pousser Í coté".
Ce genre de chose, je préfère les mettre dans des scripts, que dans l'application. C'est plus flexible. Je ne comprends pas non plus cette obsession pour les "extensions". Mais Í nouveau, mon point de vue est celui de l'intégrateur ou de l'administrateur système. Je crois que pour le moment je ne comprends pas l'objectif de ton application.
Thomas <fantome.forums.tDeContes@free.fr.invalid> wrote:
le pb est de pouvoir faire une telle procédure dans une bibliothèque, ce
qui implique que cette procédure ne connaitra pas d'avance les
extensions des fichiers qu'on va lui demander de "pousser Í coté".
Ce genre de chose, je préfère les mettre dans des scripts, que dans
l'application. C'est plus flexible. Je ne comprends pas non plus cette
obsession pour les "extensions".
Mais Í nouveau, mon point de vue est celui de l'intégrateur ou de
l'administrateur système.
Je crois que pour le moment je ne comprends pas l'objectif de
ton application.
le pb est de pouvoir faire une telle procédure dans une bibliothèque, ce qui implique que cette procédure ne connaitra pas d'avance les extensions des fichiers qu'on va lui demander de "pousser Í coté".
Ce genre de chose, je préfère les mettre dans des scripts, que dans l'application. C'est plus flexible. Je ne comprends pas non plus cette obsession pour les "extensions". Mais Í nouveau, mon point de vue est celui de l'intégrateur ou de l'administrateur système. Je crois que pour le moment je ne comprends pas l'objectif de ton application.
Marc SCHAEFER
Thomas wrote:
le pb est de pouvoir faire une telle procédure dans une bibliothèque, ce qui implique que cette procédure ne connaitra pas d'avance les extensions des fichiers qu'on va lui demander de "pousser Í coté".
Ce genre de chose, je préfère les mettre dans des scripts, que dans l'application. C'est plus flexible. Je ne comprends pas non plus cette obsession pour les "extensions". Un fichier est un fichier. Mais Í nouveau, mon point de vue est celui de l'intégrateur ou de l'administrateur système. Je crois que pour le moment je ne comprends pas l'objectif de ton application.
Thomas <fantome.forums.tDeContes@free.fr.invalid> wrote:
le pb est de pouvoir faire une telle procédure dans une bibliothèque, ce
qui implique que cette procédure ne connaitra pas d'avance les
extensions des fichiers qu'on va lui demander de "pousser Í coté".
Ce genre de chose, je préfère les mettre dans des scripts, que dans
l'application. C'est plus flexible. Je ne comprends pas non plus cette
obsession pour les "extensions". Un fichier est un fichier.
Mais Í nouveau, mon point de vue est celui de l'intégrateur ou de
l'administrateur système.
Je crois que pour le moment je ne comprends pas l'objectif de
ton application.
le pb est de pouvoir faire une telle procédure dans une bibliothèque, ce qui implique que cette procédure ne connaitra pas d'avance les extensions des fichiers qu'on va lui demander de "pousser Í coté".
Ce genre de chose, je préfère les mettre dans des scripts, que dans l'application. C'est plus flexible. Je ne comprends pas non plus cette obsession pour les "extensions". Un fichier est un fichier. Mais Í nouveau, mon point de vue est celui de l'intégrateur ou de l'administrateur système. Je crois que pour le moment je ne comprends pas l'objectif de ton application.
Nicolas George
Thomas , dans le message , a écrit :
Nicolas me suggérais par ex d'utiliser un "timestamp" Í la seconde, plutÍ´t qu'un "timestamp" au jour + un n° incrémental,
Mais pour ton problème clarifié, je ne suggère rien du tout car il est fondamentalement mal posé.
Thomas , dans le message
<fantome.forums.tDeContes-34DA16.21230820072021@news.free.fr>, a écrit :
Nicolas me suggérais par ex d'utiliser un "timestamp" Í la seconde,
plutÍ´t qu'un "timestamp" au jour + un n° incrémental,
Mais pour ton problème clarifié, je ne suggère rien du tout car il est
fondamentalement mal posé.
Nicolas me suggérais par ex d'utiliser un "timestamp" Í la seconde, plutÍ´t qu'un "timestamp" au jour + un n° incrémental,
Mais pour ton problème clarifié, je ne suggère rien du tout car il est fondamentalement mal posé.
Thomas
In article <sd0l91$b4m$, Marc SCHAEFER wrote:
Thomas wrote:
est ce que tu parles du répertoire courant (pwd), ou du répertoire
oui
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 ?) 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 ?), il me semblait que ça servait surtout comme point de départ pour les fichiers lus ou générés (mais) Í la demande de l'utilisateur. en fait, quand un logiciel a des "affaires Í lui" Í mettre qqpart, la pratique ça serais pas plutÍ´t qqch du genre "~/.config/<logiciel>/" ? en passant, je me suis aperçu fortuitement que mon logiciel change effectivement de répertoire courant au cours de son exécution, puisque n'ayant pas fait attention Í tous ces détails, je me suis retrouvé avec des fichiers de log un peu partout :-( peut il y avoir un intérêt Í faire ça ? (je n'en vois aucun, pour l'instant je ne vois que les inconvénients)
contenant le binaire du logiciel qu'on lance ?
non, c'est risqué / compliqué sous UNIX
compliqué : je ne trouve pas tant que ça : GNAT fournit une procédure ada toute faite, qui utilise notamment PATH un peu de la même manière que pathsearch dans cet exemple pour `make` : https://www.gnu.org/software/make/manual/html_node/Call-Function.html risqué : peux tu préciser un peu stp ? je proposais qu'en cas d'erreur quelconque Í l'écriture des logs, l'erreur d'écriture soit simplement ignorée silencieusement, comptant sur le fait que le même contenu sera accessible via stdout et stderr. est ce que c'est une mauvaise conception ? -- RAPID maintainer http://savannah.nongnu.org/projects/rapid/
In article <sd0l91$b4m$1@shakotay.alphanet.ch>,
Marc SCHAEFER <schaefer@alphanet.ch> wrote:
Thomas <fantome.forums.tDeContes@free.fr.invalid> wrote:
> est ce que tu parles du répertoire courant (pwd), ou du répertoire
oui
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 ?)
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 ?),
il me semblait que ça servait surtout comme point de départ pour les
fichiers lus ou générés (mais) Í la demande de l'utilisateur.
en fait, quand un logiciel a des "affaires Í lui" Í mettre qqpart, la
pratique ça serais pas plutÍ´t qqch du genre "~/.config/<logiciel>/" ?
en passant, je me suis aperçu fortuitement que mon logiciel change
effectivement de répertoire courant au cours de son exécution, puisque
n'ayant pas fait attention Í tous ces détails, je me suis retrouvé avec
des fichiers de log un peu partout :-(
peut il y avoir un intérêt Í faire ça ?
(je n'en vois aucun, pour l'instant je ne vois que les inconvénients)
> contenant le binaire du logiciel qu'on lance ?
non, c'est risqué / compliqué sous UNIX
compliqué :
je ne trouve pas tant que ça :
GNAT fournit une procédure ada toute faite, qui utilise notamment PATH
un peu de la même manière que pathsearch dans cet exemple pour `make` :
https://www.gnu.org/software/make/manual/html_node/Call-Function.html
risqué :
peux tu préciser un peu stp ?
je proposais qu'en cas d'erreur quelconque Í l'écriture des logs,
l'erreur d'écriture soit simplement ignorée silencieusement, comptant
sur le fait que le même contenu sera accessible via stdout et stderr.
est ce que tu parles du répertoire courant (pwd), ou du répertoire
oui
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 ?) 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 ?), il me semblait que ça servait surtout comme point de départ pour les fichiers lus ou générés (mais) Í la demande de l'utilisateur. en fait, quand un logiciel a des "affaires Í lui" Í mettre qqpart, la pratique ça serais pas plutÍ´t qqch du genre "~/.config/<logiciel>/" ? en passant, je me suis aperçu fortuitement que mon logiciel change effectivement de répertoire courant au cours de son exécution, puisque n'ayant pas fait attention Í tous ces détails, je me suis retrouvé avec des fichiers de log un peu partout :-( peut il y avoir un intérêt Í faire ça ? (je n'en vois aucun, pour l'instant je ne vois que les inconvénients)
contenant le binaire du logiciel qu'on lance ?
non, c'est risqué / compliqué sous UNIX
compliqué : je ne trouve pas tant que ça : GNAT fournit une procédure ada toute faite, qui utilise notamment PATH un peu de la même manière que pathsearch dans cet exemple pour `make` : https://www.gnu.org/software/make/manual/html_node/Call-Function.html risqué : peux tu préciser un peu stp ? je proposais qu'en cas d'erreur quelconque Í l'écriture des logs, l'erreur d'écriture soit simplement ignorée silencieusement, comptant sur le fait que le même contenu sera accessible via stdout et stderr. est ce que c'est une mauvaise conception ? -- RAPID maintainer http://savannah.nongnu.org/projects/rapid/
Thomas
In article <60f73204$0$6469$, Nicolas George <nicolas$ wrote:
Thomas , dans le message , a écrit :
Nicolas me suggérais par ex d'utiliser un "timestamp" Í la seconde, plutÍ´t qu'un "timestamp" au jour + un n° incrémental,
Mais pour ton problème clarifié, je ne suggère rien du tout car il est fondamentalement mal posé.
dans ce cas, pourrais tu m'aider Í le poser mieux, stp ? -- RAPID maintainer http://savannah.nongnu.org/projects/rapid/
In article <60f73204$0$6469$426a34cc@news.free.fr>,
Nicolas George <nicolas$george@salle-s.org> wrote:
Thomas , dans le message
<fantome.forums.tDeContes-34DA16.21230820072021@news.free.fr>, a écrit :
> Nicolas me suggérais par ex d'utiliser un "timestamp" Í la seconde,
> plutÍ´t qu'un "timestamp" au jour + un n° incrémental,
Mais pour ton problème clarifié, je ne suggère rien du tout car il est
fondamentalement mal posé.
dans ce cas, pourrais tu m'aider Í le poser mieux, stp ?
In article <60f73204$0$6469$, Nicolas George <nicolas$ wrote:
Thomas , dans le message , a écrit :
Nicolas me suggérais par ex d'utiliser un "timestamp" Í la seconde, plutÍ´t qu'un "timestamp" au jour + un n° incrémental,
Mais pour ton problème clarifié, je ne suggère rien du tout car il est fondamentalement mal posé.
dans ce cas, pourrais tu m'aider Í le poser mieux, stp ? -- RAPID maintainer http://savannah.nongnu.org/projects/rapid/
Thomas
In article <sd78cf$ktp$, Marc SCHAEFER wrote:
Thomas wrote:
le pb est de pouvoir faire une telle procédure dans une bibliothèque, ce qui implique que cette procédure ne connaitra pas d'avance les extensions des fichiers qu'on va lui demander de "pousser Í coté".
Ce genre de chose, je préfère les mettre dans des scripts, que dans l'application. C'est plus flexible.
ok
Je ne comprends pas non plus cette obsession pour les "extensions". Un fichier est un fichier.
de mon expérience, elles ont une certaine importance pour déterminer le type de contenu (comme dit dans le msg précédent dans le fil). il me semble même qu'il y a des applications qui refusent d'ouvrir des fichiers qui n'ont pas l'extension attendue.
Mais Í nouveau, mon point de vue est celui de l'intégrateur ou de l'administrateur système.
ok. si tu n'es pas développeur, tu ne peux pas l'inventer ... (l'es tu ?)
Je crois que pour le moment je ne comprends pas l'objectif de ton application.
(question connexe : quand dit on "application" et "logiciel" ?) - logs : (je pars de l'hypothèse o͹ la réponse Í la qu. 3 du msg est "non") 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. 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͹. - fichier d'urgence : cette application traite des fichiers .gui. en cas d'erreur critique, elle tente de générer un fichier "emergency.gui", pour nous permettre de récupérer les modifications non enregistrées. (le nom est codé en dur) 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. - code généré : il y a peut être des cas o͹ ça ne serait pas pertinent de sauver (plutÍ´t que d'écraser) un fichier de code généré automatiquement, mais ça peut l'être si la génération de code est partielle, et donc forcément destinée Í être complétée Í la main. -- RAPID maintainer http://savannah.nongnu.org/projects/rapid/
In article <sd78cf$ktp$3@shakotay.alphanet.ch>,
Marc SCHAEFER <schaefer@alphanet.ch> wrote:
Thomas <fantome.forums.tDeContes@free.fr.invalid> wrote:
> le pb est de pouvoir faire une telle procédure dans une bibliothèque, ce
> qui implique que cette procédure ne connaitra pas d'avance les
> extensions des fichiers qu'on va lui demander de "pousser Í coté".
Ce genre de chose, je préfère les mettre dans des scripts, que dans
l'application. C'est plus flexible.
ok
Je ne comprends pas non plus cette
obsession pour les "extensions". Un fichier est un fichier.
de mon expérience, elles ont une certaine importance pour déterminer le
type de contenu (comme dit dans le msg précédent dans le fil).
il me semble même qu'il y a des applications qui refusent d'ouvrir des
fichiers qui n'ont pas l'extension attendue.
Mais Í nouveau, mon point de vue est celui de l'intégrateur ou de
l'administrateur système.
ok.
si tu n'es pas développeur, tu ne peux pas l'inventer ...
(l'es tu ?)
Je crois que pour le moment je ne comprends pas l'objectif de
ton application.
(question connexe : quand dit on "application" et "logiciel" ?)
- logs :
(je pars de l'hypothèse o͹ la réponse Í la qu. 3 du msg
<fantome.forums.tDeContes-BC1C13.00324017072021@news.free.fr> est "non")
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.
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͹.
- fichier d'urgence :
cette application traite des fichiers .gui.
en cas d'erreur critique, elle tente de générer un fichier
"emergency.gui", pour nous permettre de récupérer les modifications non
enregistrées.
(le nom est codé en dur)
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.
- code généré :
il y a peut être des cas o͹ ça ne serait pas pertinent de sauver (plutÍ´t
que d'écraser) un fichier de code généré automatiquement,
mais ça peut l'être si la génération de code est partielle, et donc
forcément destinée Í être complétée Í la main.
le pb est de pouvoir faire une telle procédure dans une bibliothèque, ce qui implique que cette procédure ne connaitra pas d'avance les extensions des fichiers qu'on va lui demander de "pousser Í coté".
Ce genre de chose, je préfère les mettre dans des scripts, que dans l'application. C'est plus flexible.
ok
Je ne comprends pas non plus cette obsession pour les "extensions". Un fichier est un fichier.
de mon expérience, elles ont une certaine importance pour déterminer le type de contenu (comme dit dans le msg précédent dans le fil). il me semble même qu'il y a des applications qui refusent d'ouvrir des fichiers qui n'ont pas l'extension attendue.
Mais Í nouveau, mon point de vue est celui de l'intégrateur ou de l'administrateur système.
ok. si tu n'es pas développeur, tu ne peux pas l'inventer ... (l'es tu ?)
Je crois que pour le moment je ne comprends pas l'objectif de ton application.
(question connexe : quand dit on "application" et "logiciel" ?) - logs : (je pars de l'hypothèse o͹ la réponse Í la qu. 3 du msg est "non") 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. 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͹. - fichier d'urgence : cette application traite des fichiers .gui. en cas d'erreur critique, elle tente de générer un fichier "emergency.gui", pour nous permettre de récupérer les modifications non enregistrées. (le nom est codé en dur) 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. - code généré : il y a peut être des cas o͹ ça ne serait pas pertinent de sauver (plutÍ´t que d'écraser) un fichier de code généré automatiquement, mais ça peut l'être si la génération de code est partielle, et donc forcément destinée Í être complétée Í la main. -- RAPID maintainer http://savannah.nongnu.org/projects/rapid/
Marc SCHAEFER
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. Alternative: le fichier de config spécifié en ligne de commande (ou dans ~/.nom-application) indique o͹ se trouve
en tant qu'usager, ça m'embête d'avoir Í faire attention au répertoire courant au motif que le logiciel va mettre des choses Í lui dedans (est ce une pratique courante ?),
pas du tout, la pratique c'est un fichier de configuration :)
en fait, quand un logiciel a des "affaires Í lui" Í mettre qqpart, la pratique ça serais pas plutÍ´t qqch du genre "~/.config/<logiciel>/" ?
oui, aussi, mais en ce qui me concerne j'aime que cela soit configurable.
peut il y avoir un intérêt Í faire ça ?
Í changer de répertoire courant? non, c'est un choix de l'utilisateur, cela ne devrait pas être un choix de ton application.
risqué : peux tu préciser un peu stp ?
Je peux lancer ton logiciel comme toto/bla tu te lances comme bla tu dois alors faire: répertoire courant + "toto" pour avoir le répertoire courant de l'application. Mais voici ce que je peux faire sous UNIX (dans /tmp/tt pour la démo): Supposons que ton application s'appelle /tmp/tt/bin/bla (j'ai fait un simple cp /bin/cat /tmp/tt/bin/bla pour la démo): terminal 1: # je lance ton programme :/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. Et si tu as changé ton répertoire courant (pourquoi?), alors cela ne marchera jamais. C'est autorisé sous UNIX (pas la notion de `répertoire utilisé' comme sous Microsoft). Je ne dis pas qu'on va faire ça tous les jours, mais les bonnes pratiques UNIX consistent Í ne pas essayer de découvrir ce genre de chose et Í utiliser des fichiers de configurations statiques dans ~/.config ou dont les noms sont passés en ligne de commande. Bon, dans ce cas, la manière sÍ»re, sous Linux, d'obtenir le répertoire de l'application est via /proc/self/exe (mais ce n'est pas portable).
est ce que c'est une mauvaise conception ?
Je ne sais pas, je ne sais toujours pas pourquoi ton programme a besoin de créer des fichiers de logs plutÍ´t que d'utiliser stdout et stderr, et je ne sais pas pourquoi il a besoin d'extensions de fichiers, ni pourquoi il désire changer de répertoire courant :)
Thomas <fantome.forums.tDeContes@free.fr.invalid> wrote:
tu as dit "le répertoire courant du lancement du logiciel",
si je comprend bien, ça veut dire qu'il faut enregistrer l'emplacement
du répertoire courant au démarrage, au cas o͹ le logiciel décide d'en
changer ensuite. (ai je bien compris ?)
oui.
Alternative: le fichier de config spécifié en ligne de commande (ou dans
~/.nom-application) indique o͹ se trouve
en tant qu'usager, ça m'embête d'avoir Í faire attention au répertoire
courant au motif que le logiciel va mettre des choses Í lui dedans
(est ce une pratique courante ?),
pas du tout, la pratique c'est un fichier de configuration :)
en fait, quand un logiciel a des "affaires Í lui" Í mettre qqpart, la
pratique ça serais pas plutÍ´t qqch du genre "~/.config/<logiciel>/" ?
oui, aussi, mais en ce qui me concerne j'aime que cela soit
configurable.
peut il y avoir un intérêt Í faire ça ?
Í changer de répertoire courant? non, c'est un choix de l'utilisateur,
cela ne devrait pas être un choix de ton application.
risqué :
peux tu préciser un peu stp ?
Je peux lancer ton logiciel comme
toto/bla
tu te lances comme bla
tu dois alors faire: répertoire courant + "toto" pour avoir
le répertoire courant de l'application.
Mais voici ce que je peux faire sous UNIX (dans /tmp/tt pour la démo):
Supposons que ton application s'appelle /tmp/tt/bin/bla (j'ai fait un
simple cp /bin/cat /tmp/tt/bin/bla pour la démo):
terminal 1:
# je lance ton programme
schaefer@reliand:/tmp/tt$ bin/bla
terminal 2:
# pendant l'exécution, je change la structure des répertoires
schaefer@reliand:/tmp/tt$ mv bin toto
Suivant Í quel moment ton programme va faire répertoire courant + "bin"
pour avoir le répertoire de l'application, ça ne marchera plus.
Et si tu as changé ton répertoire courant (pourquoi?), alors cela ne
marchera jamais.
C'est autorisé sous UNIX (pas la notion de `répertoire utilisé' comme
sous Microsoft).
Je ne dis pas qu'on va faire ça tous les jours, mais les bonnes
pratiques UNIX consistent Í ne pas essayer de découvrir ce genre de
chose et Í utiliser des fichiers de configurations statiques dans
~/.config ou dont les noms sont passés en ligne de commande.
Bon, dans ce cas, la manière sÍ»re, sous Linux, d'obtenir le répertoire
de l'application est via /proc/self/exe (mais ce n'est pas portable).
est ce que c'est une mauvaise conception ?
Je ne sais pas, je ne sais toujours pas pourquoi ton programme a besoin
de créer des fichiers de logs plutÍ´t que d'utiliser stdout et stderr, et
je ne sais pas pourquoi il a besoin d'extensions de fichiers, ni
pourquoi il désire changer de répertoire courant :)
tu as dit "le répertoire courant du lancement du logiciel", si je comprend bien, ça veut dire qu'il faut enregistrer l'emplacement du répertoire courant au démarrage, au cas o͹ le logiciel décide d'en changer ensuite. (ai je bien compris ?)
oui. Alternative: le fichier de config spécifié en ligne de commande (ou dans ~/.nom-application) indique o͹ se trouve
en tant qu'usager, ça m'embête d'avoir Í faire attention au répertoire courant au motif que le logiciel va mettre des choses Í lui dedans (est ce une pratique courante ?),
pas du tout, la pratique c'est un fichier de configuration :)
en fait, quand un logiciel a des "affaires Í lui" Í mettre qqpart, la pratique ça serais pas plutÍ´t qqch du genre "~/.config/<logiciel>/" ?
oui, aussi, mais en ce qui me concerne j'aime que cela soit configurable.
peut il y avoir un intérêt Í faire ça ?
Í changer de répertoire courant? non, c'est un choix de l'utilisateur, cela ne devrait pas être un choix de ton application.
risqué : peux tu préciser un peu stp ?
Je peux lancer ton logiciel comme toto/bla tu te lances comme bla tu dois alors faire: répertoire courant + "toto" pour avoir le répertoire courant de l'application. Mais voici ce que je peux faire sous UNIX (dans /tmp/tt pour la démo): Supposons que ton application s'appelle /tmp/tt/bin/bla (j'ai fait un simple cp /bin/cat /tmp/tt/bin/bla pour la démo): terminal 1: # je lance ton programme :/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. Et si tu as changé ton répertoire courant (pourquoi?), alors cela ne marchera jamais. C'est autorisé sous UNIX (pas la notion de `répertoire utilisé' comme sous Microsoft). Je ne dis pas qu'on va faire ça tous les jours, mais les bonnes pratiques UNIX consistent Í ne pas essayer de découvrir ce genre de chose et Í utiliser des fichiers de configurations statiques dans ~/.config ou dont les noms sont passés en ligne de commande. Bon, dans ce cas, la manière sÍ»re, sous Linux, d'obtenir le répertoire de l'application est via /proc/self/exe (mais ce n'est pas portable).
est ce que c'est une mauvaise conception ?
Je ne sais pas, je ne sais toujours pas pourquoi ton programme a besoin de créer des fichiers de logs plutÍ´t que d'utiliser stdout et stderr, et je ne sais pas pourquoi il a besoin d'extensions de fichiers, ni pourquoi il désire changer de répertoire courant :)
Marc SCHAEFER
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.
(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).
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.
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 (appelé par exemple .gui.backup vu que tu adores les extensions).
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.
(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).
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.
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 (appelé par exemple
.gui.backup vu que tu adores les extensions).
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.
(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).
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.
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 (appelé par exemple .gui.backup vu que tu adores les extensions).
Nicolas George
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.
Thomas , dans le message
<fantome.forums.tDeContes-8A99BF.23331420072021@news.free.fr>, a écrit :
dans ce cas, pourrais tu m'aider Í le poser mieux, stp ?
