Path: ...!weretis.net!feeder6.news.weretis.net!feeder8.news.weretis.net!feeder1.feed.usenet.farm!feed.usenet.farm!news.uzoreto.com!npeer.as286.net!npeer-ng0.as286.net!proxad.net!feeder1-1.proxad.net!cleanfeed1-b.proxad.net!nnrp1-2.free.fr!not-for-mail
From: Thomas <fantome.forums.tDeContes@free.fr.invalid>
Newsgroups: fr.comp.os.unix
Mail-Copies-To: nobody
Subject: Re: =?ISO-8859-1?Q?g=E9rer?= des fichiers log
References: <fantome.forums.tDeContes-AD48E3.21414905072021@news.free.fr> <60e4f85a$0$6200$426a34cc@news.free.fr> <sc3g39$igb$2@shakotay.alphanet.ch> <fantome.forums.tDeContes-815480.23034116072021@news.free.fr> <scubs2$u25$2@shakotay.alphanet.ch> <fantome.forums.tDeContes-F23835.20444917072021@news.free.fr> <sd0l91$b4m$1@shakotay.alphanet.ch> <fantome.forums.tDeContes-130E7D.23050920072021@news.free.fr> <sd8faa$8ac$1@shakotay.alphanet.ch> <fantome.forums.tDeContes-433B13.01575723072021@news.free.fr> <sddoan$flh$1@shakotay.alphanet.ch>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: MT-NewsWatcher/3.5.3b3 (Intel Mac OS X)
Date: Sun, 19 Sep 2021 19:23:55 +0200
Message-ID: <fantome.forums.tDeContes-5442BA.19235419092021@news.free.fr>
Lines: 252
Organization: Guest of ProXad - France
NNTP-Posting-Date: 19 Sep 2021 19:23:55 CEST
NNTP-Posting-Host: 91.175.52.121
X-Trace: 1632072235 news-4.free.fr 28613 91.175.52.121:3338
X-Complaints-To: abuse@proxad.net
Bytes: 10947

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

========== REMAINDER OF ARTICLE TRUNCATED ==========