Re: Gestion de caractères accentués différentes entre xterm, d'autres émulateurs de terminal, et Emacs (locales correctes)
Bonjour, Pour des raisons de commodités, je vous conseille de passer par "detox" pour les noms de fichiers... Documentation : https://linux.die.net/man/1/detox https://forum.ubuntu-fr.org/viewtopic.php?id=282633 Merci pour votre aimable attention Bien à vous Bernard
Re: Gestion de caractères accentués différentes entre xterm, d'autres émulateurs de terminal, et Emacs (locales correctes)
Merci beaucoup pour cette première piste ! Oui, je pourrais renommer le fichier, c'est parfois ce que je fais, mais c'est assez fastidieux à faire à chaque fichier reçu ;-) Comme proposé, j'ai essayé "mv r?f?rent.pdf référent.pdf", mais cela ne fonctionne pas. Un simple "ls r?f?rent.pdf" m'indique "ls: impossible d'accéder à 'r?f?rent.pdf': Aucun fichier ou dossier de ce type" alors que "ls r*.pdf" me renvoie bien le fichier. Dans mon précédent message, j'avais copié-collé l'affichage obtenu dans chaque terminal. Du coup, j'ai repris l'idée d'utiliser hexdump avec le même fichier dans un répertoire. Pour comparer, j'ai ajouté un fichier que j'ai créé moi-même avec la commande "touch référent.pdf". Avec "ls | hexdump -C", j'obtiens : 72 65 cc 81 66 65 cc 81 72 65 6e 74 2e 70 64 66 |re..fe..rent.pdf| 0010 0a 72 c3 a9 66 c3 a9 72 65 6e 74 2e 70 64 66 0a |.r..f..rent.pdf.| 0020 La deuxième ligne (fichier que j'ai créé) me semble assez bizarre avec un espace devant le premier "r" ! Autre bizarrerie, un affichage du contenu du répertoire sous midnight commander (mc) affiche les deux noms de fichiers correctement. J'ai l'impression que les "é" sont affichés de la même manière à moins que ls différences soient très subtiles. Le ven. 28 oct. 2022 11:10, Charles Plessy a écrit: > From: Charles Plessy > Subject: Re: Gestion de caractères accentués différentes entre xterm, > d'autres émulateurs de terminal, et Emacs (locales correctes) > To: debian-user-french@lists.debian.org > Mail-Followup-To: debian-user-french@lists.debian.org > Resent-From: debian-user-french@lists.debian.org > > Le Fri, Oct 28, 2022 at 12:50:19AM +0200, Jean-Philippe Georget a écrit : >> >> Sous xterm, ce fichier s'affiche correctement comme "référent.pdf" avec la >> commande "ls". >> >> Par contre, sous xfce4-terminal, il s'affiche bizarrement comme >> "référent.pdf" (notez les accents décalés sur la droite des "e"). > > Bonjour, > > c'est un problème de prise en charge d'Unicode. > > Sur mon terminal, je vois référent.pdf dans les deux cas. Mais voici > ce que je vois si je copie-colle le nom de ficher et le passe à hexdump. > > echo référent.pdf | hexdump -C > 72 c3 a9 66 c3 a9 72 65 6e 74 2e 70 64 66 0a |référent.pdf.| > 000f > > echo référent.pdf | hexdump -C > 72 65 cc 81 66 65 cc 81 72 65 6e 74 2e 70 64 66 |re?.fe?.rent.pdf| > 0010 0a|.| > 0011 > > Pour un peu plus de contexte, voici une version pure ASCII sans accents: > > echo referent.pdf | hexdump -C > 72 65 66 65 72 65 6e 74 2e 70 64 66 0a |referent.pdf.| > 000d > > Et lettre par lettre: > > printf é | hexdump -C > c3 a9 |é| > 0002 > > printf e | hexdump -C > 65|e| > 0001 > > printf é | hexdump -C > 65 cc 81 |e?.| > 0003 > > Le dernier é, c'est un e auquel on ajoute ensuite un accent aigu. > > Le caractère Unicode U+0301 COMBINING ACUTE ACCENT est encodé cc81 en UTF-8. > > Je dois m'arrêter là car mon train arrive en gare, mais une solution > pour contourner le problème pourrait être: > > mv r?f?rent.pdf référent.pdf > > Ceci change le nom de fichier pour utiliser la représentation la plus > habituelle. > > D'autres abonnés à cette liste pourront t'indiquer des outils pour le > faire automatiquement. > > Amicalement, > > Charles Plessy
Re: Gestion de caractères accentués différentes entre xterm, d'autres émulateurs de terminal, et Emacs (locales correctes)
Le Fri, Oct 28, 2022 at 12:50:19AM +0200, Jean-Philippe Georget a écrit : > > Sous xterm, ce fichier s'affiche correctement comme "référent.pdf" avec la > commande "ls". > > Par contre, sous xfce4-terminal, il s'affiche bizarrement comme > "référent.pdf" (notez les accents décalés sur la droite des "e"). Bonjour, c'est un problème de prise en charge d'Unicode. Sur mon terminal, je vois référent.pdf dans les deux cas. Mais voici ce que je vois si je copie-colle le nom de ficher et le passe à hexdump. echo référent.pdf | hexdump -C 72 c3 a9 66 c3 a9 72 65 6e 74 2e 70 64 66 0a |référent.pdf.| 000f echo référent.pdf | hexdump -C 72 65 cc 81 66 65 cc 81 72 65 6e 74 2e 70 64 66 |re?.fe?.rent.pdf| 0010 0a|.| 0011 Pour un peu plus de contexte, voici une version pure ASCII sans accents: echo referent.pdf | hexdump -C 72 65 66 65 72 65 6e 74 2e 70 64 66 0a |referent.pdf.| 000d Et lettre par lettre: printf é | hexdump -C c3 a9 |é| 0002 printf e | hexdump -C 65|e| 0001 printf é | hexdump -C 65 cc 81 |e?.| 0003 Le dernier é, c'est un e auquel on ajoute ensuite un accent aigu. Le caractère Unicode U+0301 COMBINING ACUTE ACCENT est encodé cc81 en UTF-8. Je dois m'arrêter là car mon train arrive en gare, mais une solution pour contourner le problème pourrait être: mv r?f?rent.pdf référent.pdf Ceci change le nom de fichier pour utiliser la représentation la plus habituelle. D'autres abonnés à cette liste pourront t'indiquer des outils pour le faire automatiquement. Amicalement, Charles Plessy
Gestion de caractères accentués différentes entre xterm, d'autres émulateurs de terminal, et Emacs (locales correctes)
Bonjour à tous, Je n'arrive pas à régler deux problèmes (qui ont l'air liés) que j'ai depuis plusieurs mois avec Debian (testing, à jour). Jusqu'à maintenant, je fais avec ces problèmes mais aujourd'hui je serais ravi de m'en débarrasser. J'ai fait des recherches sur le web en français et en anglais et sur la liste debian-french mais je n'ai pas trouvé de solutions. Je tente donc ma chance ici sur la liste. On m'a envoyé un fichier "référent.pdf" que je prends comme exemple mais les mêmes problèmes décrits ci-dessous se produisent avec les fichiers qu'on m'envoie, pas avec ceux que je créée. Sous xterm, ce fichier s'affiche correctement comme "référent.pdf" avec la commande "ls". Par contre, sous xfce4-terminal, il s'affiche bizarrement comme "référent.pdf" (notez les accents décalés sur la droite des "e"). Quand j'édite le nom du fichier en ligne de commande sous bash, un backspace efface le caractère de gauche, normal. Quand j'arrive à la position juste à droit des accents, chaque "e" s'efface en même temps que son accent "associé". Mais quand j'édite le nom de fichier sous le gestionnaire de fichier ranger (programmé en python), si je me mets par exemple à droite du "t" et que j'appuie sur backspace pour effacer cette lettre, il efface le "e" de "ent", soit 2 lettres à gauche de la position du curseur au lieu d'effacer le caractère juste à gauche. Le décalage similaire se produit quand j'utilise la touche DEL. J'ai essayé d'autres émulateurs de terminal : gnome-terminal, terminator, et lxterminal. Je rencontre les mêmes problèmes. Je pensais à un problème de locales. J'ai tenté un "sudo dpkg-reconfigure locales" mais sans que cela ne résolve aucun problème. La commande "locale" me renvoie des informations qui m'ont l'air correctes, comme celles que j'ai trouvées sur le net. LANG=fr_FR.UTF-8 LANGUAGE=fr_FR:en_US LC_CTYPE="fr_FR.UTF-8" LC_NUMERIC="fr_FR.UTF-8" LC_TIME="fr_FR.UTF-8" LC_COLLATE="fr_FR.UTF-8" LC_MONETARY="fr_FR.UTF-8" LC_MESSAGES="fr_FR.UTF-8" LC_PAPER="fr_FR.UTF-8" LC_NAME="fr_FR.UTF-8" LC_ADDRESS="fr_FR.UTF-8" LC_TELEPHONE="fr_FR.UTF-8" LC_MEASUREMENT="fr_FR.UTF-8" LC_IDENTIFICATION="fr_FR.UTF-8" LC_ALL= J'ai ensuite pensé à un problème de fonte. Mon xfce4-terminal utilisait "Monospace Regular", j'ai alors testé d'autres fontes. J'arrive à résoudre le problème d'affichage mais pas celui de l'effacement expliqué plus haut, il y a toujours un décalage de 2 caractères. Sous Emacs 27.1, j'ai le même problème d'affichage et d'effacement de caractères sous dired. J'ai tenté de lancer "emacs -q" depuis le xterm puisqu'il n'y avait pas de problème sous xterm, mais je rencontre les mêmes problèmes sous dired. J'ai aussi créé un nouvel utilisateur sous ma machine pour voir si cela ne viendrait d'un problème de configuration quelque part au niveau de mon profil utilisateur : les problèmes rencontrés sont les mêmes. Si vous avez des idées de solution, je suis (très) preneur ! :-) Jean-Philippe
Re: Lenteur de démarrage extrême de Libreoffice
Le 27/10/2022 à 23:08, Sébastien Dinot a écrit : Le débit en lecture directe n'est que de 72 Mo/s ! Je suis très loin des 500 Mo/s annoncés par le constructeur : https://www.kingston.com/en/ssd/a400-solid-state-drive?partnum=sa400s37%2F960g Pourtant, ce disque est branché sur un port SATA 6G, dont la bande passante théorique est compatible avec un disque SSD au débit de 500 Mo/s. Je ne m'explique donc pas le calamiteux 72 Mo/s. :( Sébastien - Dans le bios, le port sata est bien en mode ahci? - Tu as passé l'utilitaire constructeur pour voir son état? - firmware à jour? - Disque pas trop rempli? - Ton système lance bien régulièrement la commande fstrim sur chaque partition montée? chez moi c'est une fois par semaine. Je pensais que je n'écrivais pas beaucoup, mais en regardant le dernier fstrim, il a 'libéré' 47 Go (probablement à cause du cache de Firefox).
Re: Lenteur de démarrage extrême de Libreoffice
Bonsoir, Th.A.C a écrit : > Déja pour remettre un peu à plat les différences entre les 2 machines: > > - un ssd sata d'un coté avec des débit max à 550Mo/s > - un ssd nvme de l'autre avec des débits qui peuvent monter à 3,5Go/s > (6 Go/s sur les dernières génération si la carte mère le supporte). Comme la machine et son processeur, le disque NVMe qui équipe la seconde machine date de 2017. Il y a 5 ans, les performances des disques NVMe (pourtant révolutionnaires à l'époque) étaient très en deça de celles offertes par les modèles les plus récents, dédiés aux serveurs ou aux utilisateurs fortunés. Le disque NVMe en question était plutôt annoncé autour des 1 Go/s en lecture et écriture. Mais cet échange m'a amené à faire un test simple pour vérifier ce que je m'apprêtais à écrire et j'ai eu une très mauvaise surprise. Sur la machine dotée du disque NVMe, j'ai exécuté 3 fois de suite la commande : # hdparm -tT --direct /dev/nvme0n1 Voici le résultat : /dev/nvme0n1: Timing O_DIRECT cached reads: 1420 MB in 2.00 seconds = 709.95 MB/sec Timing O_DIRECT disk reads: 2710 MB in 3.00 seconds = 902.74 MB/sec /dev/nvme0n1: Timing O_DIRECT cached reads: 1454 MB in 2.00 seconds = 726.71 MB/sec Timing O_DIRECT disk reads: 2684 MB in 3.00 seconds = 893.97 MB/sec /dev/nvme0n1: Timing O_DIRECT cached reads: 1480 MB in 2.00 seconds = 740.26 MB/sec Timing O_DIRECT disk reads: 2708 MB in 3.00 seconds = 901.87 MB/sec Donc, en lecture directe (i.e. sans utilisation du cache), ce disque offre un débit moyen de 900 Mo/s. Voici ce que donne la commande équivalente (hdparm -tT --direct /dev/sda) sur la machine dotée d'un disque SSD : /dev/sda: Timing O_DIRECT cached reads:34 MB in 2.10 seconds = 16.19 MB/sec Timing O_DIRECT disk reads: 226 MB in 3.13 seconds = 72.20 MB/sec /dev/sda: Timing O_DIRECT cached reads:36 MB in 2.10 seconds = 17.13 MB/sec Timing O_DIRECT disk reads: 226 MB in 3.19 seconds = 70.88 MB/sec /dev/sda: Timing O_DIRECT cached reads:36 MB in 2.05 seconds = 17.58 MB/sec Timing O_DIRECT disk reads: 226 MB in 3.13 seconds = 72.16 MB/sec Le débit en lecture directe n'est que de 72 Mo/s ! Je suis très loin des 500 Mo/s annoncés par le constructeur : https://www.kingston.com/en/ssd/a400-solid-state-drive?partnum=sa400s37%2F960g Pourtant, ce disque est branché sur un port SATA 6G, dont la bande passante théorique est compatible avec un disque SSD au débit de 500 Mo/s. Je ne m'explique donc pas le calamiteux 72 Mo/s. :( Sébastien -- Sébastien Dinot, sebastien.di...@free.fr http://www.palabritudes.net/ Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passer !
Re: Lenteur de démarrage extrême de Libreoffice
Déja pour remettre un peu à plat les différences entre les 2 machines: - un ssd sata d'un coté avec des débit max à 550Mo/s - un ssd nvme de l'autre avec des débits qui peuvent monter à 3,5Go/s (6 Go/s sur les dernières génération si la carte mère le supporte). A noter qu'il n'y a pas que le débit qui est accéléré, l'envoi des commandes est lui aussi plus rapide. - 4 coeurs sur le plus ancien et 8 coeurs sur le plus récent avec 4 générations de différence (c'est énorme comme différence) - ddr3 d'un coté, ddr4 de l'autre avec le double de ram - le ssd nvme est chiffré mais on a 8 coeurs et de la ddr4 on ne sait pas qui déchiffre le ssd: le proc, la puce tpm,...? Bref, sur le plus récent on a au minimum le double de puissance sur tout (proc, ram) et bien plus sur le disque et très probablement le proc...
Re: Lenteur de démarrage extrême de Libreoffice
Le Thu, 27 Oct 2022 09:58:42 +0200, Sébastien Dinot a écrit : > * Sur la machine A, j'ai 906 ouvertures de fichiers True Type, du > genre : > > openat(AT_FDCWD, "/usr/share/fonts/truetype/dejavu/DejaVuSans.ttf", > O_RDONLY) = 5 > > Ils s'effectuent en 20,9 secondes. > > * Sur la machine B, j'ai 2952 uvertures de fichiers True Type. Ils > s'effectuent en 4,5 secondes. > > Autrement dit, sur la machine dotée d'un NVMe chiffré, la lecture de > 3 fois plus de fichiers s'effectue en 5 fois moins de temps (donc un > ratio de 15) que sur une machine dotée d'un SSD non chiffré et récent. > > J'ai du mal à croire qu'un tel écart ne soit imputable qu'au matériel. > Qu'en pensez-vous ? Rencontrez-vous le même genre de problème ? Si c'est un problème de chargement de polices, n'y aurait-il pas d'autres différences de config qui pourraient influer, comme l'utilisation d'openCL, de configuration de cache ou autre ? Je n'ai aucune idée de la manière dont les polices sont traitées tant en terme d'i/o qu'en terme de calcul graphique.
Lenteur de démarrage extrême de Libreoffice
Bonjour, J'ai un souci avec LibreOffice sur l'une de mes machines qui me turlupine et j'aimerais avoir votre avis à ce sujet. Sur la machine A, le premier démarrage de Libreoffice, même sans ouvrir de document, prend environ 25 secondes. Les démarrages suivants prennent moins de 2 secondes. Sur la machine B, le premier démarrage de Libreoffice dans les mêmes conditions prend moins de 10 secondes. Les démarrages suivants prennent moins de 2 secondes. Machine A : * Année : 2012 * Intel Core i5-3570K @ 4x 3.8GHz * 16 Go de RAM DDR3 à 1333 MHz (0.8 ns) * disque SSD 1 To récent *non* chiffré * Debian Bullseye (stable) * LibreOffice 7.0.4 Machine B : * Année : 2017 * Intel Core i7-7700HQ @ 8x 3.8GHz * 32 Go de RAM DDR4 à 2667 MHz (0,4 ns) * disque NVMe 512 Go chiffré * Debian Bookworm (testing) * LibreOffice 7.4.1 Alors certes, les machines ne sont pas de même génération, mais la plus vieille n'est pas un veau et dispose d'une quantité généreuse de RAM et d'un disque SSD récent. Pour ceux à qui cela parlera, j'édite sans problème sur cette machine de très gros jeux de données dans JOSM, qui consomme alors jusqu'à 7 Go de RAM. La plus récente a par ailleurs un petit handicap, son disque NVMe est chiffré, ce qui dégrade un peu ses performances en lecture (et beaucoup en écriture). Pour essayer de comprendre ce qui se passait, j'ai utilisé la commande « libreoffice --strace » et là, j'ai constaté que : * Sur la machine A, j'ai 906 ouvertures de fichiers True Type, du genre : openat(AT_FDCWD, "/usr/share/fonts/truetype/dejavu/DejaVuSans.ttf", O_RDONLY) = 5 Ils s'effectuent en 20,9 secondes. * Sur la machine B, j'ai 2952 uvertures de fichiers True Type. Ils s'effectuent en 4,5 secondes. Autrement dit, sur la machine dotée d'un NVMe chiffré, la lecture de 3 fois plus de fichiers s'effectue en 5 fois moins de temps (donc un ratio de 15) que sur une machine dotée d'un SSD non chiffré et récent. J'ai du mal à croire qu'un tel écart ne soit imputable qu'au matériel. Qu'en pensez-vous ? Rencontrez-vous le même genre de problème ? Sébastien PS : Au passage, je suis surpris de voir que LibreOffice ouvre au moins deux fois chaque fichier TrueType. -- Sébastien Dinot, sebastien.di...@free.fr http://www.palabritudes.net/ Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passer !
