Path: csiph.com!newsfeed.xs4all.nl!newsfeed8.news.xs4all.nl!news.uzoreto.com!news.alphanet.ch!alphanet.ch!.POSTED.localhost!not-for-mail From: Marc SCHAEFER Newsgroups: fr.comp.os.unix Subject: Re: =?ISO-8859-1?Q?g=E9rer?= des fichiers log Date: Thu, 22 Jul 2021 18:58:14 -0000 (UTC) Organization: Posted through ALPHANET (https://news.alphanet.ch/) Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Injection-Date: Thu, 22 Jul 2021 18:58:14 -0000 (UTC) Injection-Info: shakotay.alphanet.ch; posting-host="localhost:127.0.0.1"; logging-data="17082"; mail-complaints-to="usenet@alphanet.ch" User-Agent: tin/2.4.3-20181224 ("Glen Mhor") (UNIX) (Linux/4.19.0-17-amd64 (x86_64)) Cancel-Lock: sha256:JW39g4pbaz7avGikV08TxB6w3b7mrfIggsy+ta0axSI= Xref: csiph.com fr.comp.os.unix:7757 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_prefix= log_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= 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.