Path: ...!news.roellig-ltd.de!open-news-network.org!news.dns-netz.com!news.freedyn.net!newsfeed.xs4all.nl!newsfeed7.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: Mon, 20 Sep 2021 12:29:37 -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: Mon, 20 Sep 2021 12:29:37 -0000 (UTC) Injection-Info: shakotay.alphanet.ch; posting-host="localhost:127.0.0.1"; logging-data="22861"; 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:NLhxWs6OlSuEsP2sdSLALQ3Hn/0suG6vll0RQIsrFUw= Bytes: 8129 Lines: 166 Thomas 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.