Re: commande 'sort' et la localisation...
On Sun, Jan 01, 2006 at 09:46:20PM +0100, Yves Rutschle wrote: [Après la bataille...] On Thu, Dec 29, 2005 at 07:42:15PM +0100, Denis Barbier wrote: A priori c'est le 2e que l'on veut, c'est pourquoi utiliser LC_COLLATE pour ls est judicieux. Idem pour les majuscules, on préfère Aalto anneaux lune Lyre tmp à Aalto Lyre anneaux lune tmp Personnellement, je ne suis pas d'accord avec ça. Dans la vieille tradition Unix, on écrit README, INSTALL, etc en majuscule pour qu'ils apparaissent en premier dans la sortie de ls. Et pour l'exemple d'avant, avec les lettres accentuées ? De même que les problèmes de Jacques (d'après ce que j'ai compris vu de loin) sont dus à son utilisation de commandes et de scripts Unix conçus avant que les commandes ne commencent à changer de comportement quand on leur change leur locale. D'après http://cvs.savannah.gnu.org/viewcvs/coreutils/src/ls.c?rev=1.215root=coreutilsview=markup ce changement est apparu en 2000, et était donc déjà dans Woody. Honnêtement, je ne vois pas de solution qui soit intuitive pour tous ces cas de figure, c'est pourquoi il faudrait toujours utiliser les regexps en locale C. Pour reprendre ton exemple : LC_ALL=C mv -v [a-lA-L]* tmp J'aurais tendance à dire que si on change la sémantique d'une commande (comme il se passe ici en changeant les locales) il faudrait en fait changer le nom de la commande. Ça me rappelle un peu le débat qu'il y a eu il y a quelques années sur le remplacement de 'rm' par une commande qui déplace les fichiers dans une poubelle. Vouloir une telle commande est justifié, mais comme elle a une sémantique différente, elle devrait avoir un nom différent. De même, mv avait une sémantique précise et indépendante du pays. Il aurait mieux valu créer un ensemble de commandes localisées (lrm, lls, lmv...?) et ne pas changer la sémantique des commandes traditionnelles. Ce qui se passe avec les locales sur les commandes traditionnelles revient en fait à changer une API, dont certains programmeurs ont tendance à dire que c'est pas bien :) Le comportement de ces commandes est défini par POSIX. Une ch'tite recherche sur Google indique http://www.opengroup.org/austin/mailarchives/austin-group-l/msg02091.html Apparemment ce problème a été discuté longuement. Denis -- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Pensez à rajouter le mot ``spam'' dans vos champs From et Reply-To: To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: commande 'sort' et la localisation...
[Après la bataille...] On Thu, Dec 29, 2005 at 07:42:15PM +0100, Denis Barbier wrote: A priori c'est le 2e que l'on veut, c'est pourquoi utiliser LC_COLLATE pour ls est judicieux. Idem pour les majuscules, on préfère Aalto anneaux lune Lyre tmp à Aalto Lyre anneaux lune tmp Personnellement, je ne suis pas d'accord avec ça. Dans la vieille tradition Unix, on écrit README, INSTALL, etc en majuscule pour qu'ils apparaissent en premier dans la sortie de ls. De même que les problèmes de Jacques (d'après ce que j'ai compris vu de loin) sont dus à son utilisation de commandes et de scripts Unix conçus avant que les commandes ne commencent à changer de comportement quand on leur change leur locale. Honnêtement, je ne vois pas de solution qui soit intuitive pour tous ces cas de figure, c'est pourquoi il faudrait toujours utiliser les regexps en locale C. Pour reprendre ton exemple : LC_ALL=C mv -v [a-lA-L]* tmp J'aurais tendance à dire que si on change la sémantique d'une commande (comme il se passe ici en changeant les locales) il faudrait en fait changer le nom de la commande. Ça me rappelle un peu le débat qu'il y a eu il y a quelques années sur le remplacement de 'rm' par une commande qui déplace les fichiers dans une poubelle. Vouloir une telle commande est justifié, mais comme elle a une sémantique différente, elle devrait avoir un nom différent. De même, mv avait une sémantique précise et indépendante du pays. Il aurait mieux valu créer un ensemble de commandes localisées (lrm, lls, lmv...?) et ne pas changer la sémantique des commandes traditionnelles. Ce qui se passe avec les locales sur les commandes traditionnelles revient en fait à changer une API, dont certains programmeurs ont tendance à dire que c'est pas bien :) Y. - mouche du coche -- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Pensez à rajouter le mot ``spam'' dans vos champs From et Reply-To: To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: commande 'sort' et la localisation...
On Sun, Jan 01, 2006 at 11:24:11PM +0100, Denis Barbier wrote: Personnellement, je ne suis pas d'accord avec ça. Dans la vieille tradition Unix, on écrit README, INSTALL, etc en majuscule pour qu'ils apparaissent en premier dans la sortie de ls. Et pour l'exemple d'avant, avec les lettres accentuées ? Peut importe, vu que les accents n'étaient pas dans ascii de toute façon: c'est une extension d'API. Changer l'ordre des mots qui commencent en majuscule, c'est un changement d'API. Pour faire un parallèle, en C, on n'a _pas_ touché à la famille des str* (strlen strcat etc), on a ajouté un nouvel ensemble d'APIs (wcslen, wcscat etc). Si on prend le point de vue que les commandes Unix sont une API, ce qui a été fait revient à changer l'API. D'après http://cvs.savannah.gnu.org/viewcvs/coreutils/src/ls.c?rev=1.215root=coreutilsview=markup ce changement est apparu en 2000, et était donc déjà dans Woody. Possible, j'avais tendance à l'époque à laisser autant de mes LC_ que possible à 'C'... http://www.opengroup.org/austin/mailarchives/austin-group-l/msg02091.html Apparemment ce problème a été discuté longuement. Là dedans, je vois des discussions sur les problèmes d'expression régulières, plutôt que sur l'éventuel cassage de scripts existants en changeant l'API Unix. A+ Y. -- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Pensez à rajouter le mot ``spam'' dans vos champs From et Reply-To: To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: commande 'sort' et la localisation...
Denis Barbier a écrit, jeudi 29 décembre 2005, à 00:25 : On Wed, Dec 28, 2005 at 11:34:26PM +0100, Jacques L'helgoualc'h wrote: .tmp $ mv -v [a-l]* tmp/ `Aalto' - `tmp/Aalto' `anneaux' - `tmp/anneaux' `lune' - `tmp/lune' .tmp $ ls -l total 8 -rw-r--r-- 1 lhh lhh 0 2005-12-28 23:15 Lyre drwxr-xr-x 2 lhh lhh 4096 2005-12-28 23:20 tmp Pourquoi Aalto bouge-t-il, et pas Lyre ? Comme comportement /par défaut/, ça me paraît incohérent... En gros, c'est parce que l'ordre est a A b B c C ... k K l L m M ... Donc A est entre a et l, mais pas L. Oui, mais ça ne correspond pas à l'ordre affiché... En pratique, tu peux utiliser LC_COLLATE=C, C'est sans doute le plus simple. il est très rare d'avoir besoin du tri lexicographique. C'est tout de même utile de temps en temps, mais beaucoup moins que ls. Il me semble donc que le comportement par défaut de sort est mal choisi. Merci, -- Jacques L'helgoualc'h -- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Pensez à rajouter le mot ``spam'' dans vos champs From et Reply-To: To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: commande 'sort' et la localisation...
On Thu, Dec 29, 2005 at 10:28:32AM +0100, Jacques L'helgoualc'h wrote: Denis Barbier a écrit, jeudi 29 décembre 2005, à 00:25 : En gros, c'est parce que l'ordre est a A b B c C ... k K l L m M ... Donc A est entre a et l, mais pas L. Oui, mais ça ne correspond pas à l'ordre affiché... Et oui, ce n'est pas aussi simple qu'on pourrait le croire de prime abord, c'est justement pourquoi j'ai écrit le document mentionné avant ;) En pratique, tu peux utiliser LC_COLLATE=C, C'est sans doute le plus simple. il est très rare d'avoir besoin du tri lexicographique. C'est tout de même utile de temps en temps, mais beaucoup moins que ls. Il me semble donc que le comportement par défaut de sort est mal choisi. Heu, ça n'a rien à voir, ls n'appelle pas sort. Denis -- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Pensez à rajouter le mot ``spam'' dans vos champs From et Reply-To: To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: commande 'sort' et la localisation...
Denis Barbier a écrit, jeudi 29 décembre 2005, à 11:13 : On Thu, Dec 29, 2005 at 10:28:32AM +0100, Jacques L'helgoualc'h wrote: Denis Barbier a écrit, jeudi 29 décembre 2005, à 00:25 : En gros, c'est parce que l'ordre est a A b B c C ... k K l L m M ... Donc A est entre a et l, mais pas L. Oui, mais ça ne correspond pas à l'ordre affiché... Et oui, ce n'est pas aussi simple qu'on pourrait le croire de prime abord, c'est justement pourquoi j'ai écrit le document mentionné avant ;) Oui, il est très bien... [...] il est très rare d'avoir besoin du tri lexicographique. C'est tout de même utile de temps en temps, mais beaucoup moins que ls. Il me semble donc que le comportement par défaut de sort est mal choisi. Heu, ça n'a rien à voir, ls n'appelle pas sort. Bon, ils utilisent la même définition de l'ordre... Il me semble que ls ne devrait pas oublier le point, par exemple. C'est ce que tu veux dire par « Possible collisions with repertoire maps » ? -- Jacques L'helgoualc'h -- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Pensez à rajouter le mot ``spam'' dans vos champs From et Reply-To: To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: commande 'sort' et la localisation...
On Thu, Dec 29, 2005 at 11:41:40AM +0100, Jacques L'helgoualc'h wrote: [...] il est très rare d'avoir besoin du tri lexicographique. C'est tout de même utile de temps en temps, mais beaucoup moins que ls. Il me semble donc que le comportement par défaut de sort est mal choisi. Heu, ça n'a rien à voir, ls n'appelle pas sort. Bon, ils utilisent la même définition de l'ordre... Il me semble que ls ne devrait pas oublier le point, par exemple. Comme ls et sort utilisent tous les deux le contenu de la variable LC_COLLATE, il est difficile d'avoir un comportement différent par défaut. Ce qu'on peut faire, c'est de changer la définition de fr_FR pour tenir compte des symboles de ponctuation (et de l'espace ?), et ajouter une autre variante, p.ex. [EMAIL PROTECTED], qui permet d'avoir accès au tri lexicographique quand on en a besoin. Je n'avais pas compris ce que tu disais au sujet de « sort -d » dans tes précédents messages. Pour le français, ça n'a effectivement pas d'effet, mais pour certaines locales (comme C), elle en a un. Il faudrait vérifier dans les sources, mais il est probable que si sort est utilisé avec les options -b/d/f/i, le fichier d'entrée passe d'abord par un filtre et est stocké dans un fichier intermédiaire. Par exemple avec -d, seuls les lettres, chiffres et blancs seront écrits. Avec -f, tout est converti en minuscules (ou majuscules). Etc. Ensuite, la commande sort va trier ce fichier temporaire en tenant compte de la locale actuelle, et l'index de permutation des lignes appliqué au fichier original fournit le résultat attendu. C'est ce que tu veux dire par « Possible collisions with repertoire maps » ? Non. Les repertoire maps servaient à remplacer des caractères non-ASCII par une représentation ASCII. Par exemple, « é » pouvait être représenté par « e' », ce qui permettait d'avoir des fichiers de définitions entièrement en ASCII, de la même façon qu'on peut écrire \'e en TeX. Comme ces définitions de symboles n'étaient pas standardisées, il était possible que 2 repertoire maps différents utilisent la même représentation pour 2 caractères différents, c'est ce que j'appelais le risque de collision. L'utilisation de la notation U permet d'éviter ce problème. Denis -- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Pensez à rajouter le mot ``spam'' dans vos champs From et Reply-To: To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: commande 'sort' et la localisation...
Denis Barbier a écrit, jeudi 29 décembre 2005, à 15:56 : On Thu, Dec 29, 2005 at 11:41:40AM +0100, Jacques L'helgoualc'h wrote: [tri lexicographique ou pas] [...] Comme ls et sort utilisent tous les deux le contenu de la variable LC_COLLATE, il est difficile d'avoir un comportement différent par défaut. D'accord. Du coup, c'est l'appel à LC_COLLATE qui me paraît douteux pour ls... quand les noms de fichiers seront en UTF-*, ce sera une autre paire de manches. Ce qu'on peut faire, c'est de changer la définition de fr_FR pour tenir compte des symboles de ponctuation (et de l'espace ?), et ajouter une autre variante, p.ex. [EMAIL PROTECTED], qui permet d'avoir accès au tri lexicographique quand on en a besoin. Oui --- mais il y a déjà « sort -d » pour ça, après tout... Je n'avais pas compris ce que tu disais au sujet de « sort -d » dans tes précédents messages. Pour le français, ça n'a effectivement pas d'effet, mais pour certaines locales (comme C), elle en a un. Ben, une option, c'est fait pour modifier le comportement par défaut :) La page de man (sarge) française de sort ne met pas en garde contre cela, alors que $ LC_ALL=C man sort [...] *** WARNING *** The locale specified by the environment affects sort order. Set LC_ALL=C to get the traditional sort order that uses native byte values. Je ne jette pas la pierre au traducteur, c'est vraiment un travail de Sysyphe... Il faudrait vérifier dans les sources, [...] Merci pour tes explications très claires. -- Jacques L'helgoualc'h -- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Pensez à rajouter le mot ``spam'' dans vos champs From et Reply-To: To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: commande 'sort' et la localisation...
On Thu, Dec 29, 2005 at 04:45:27PM +0100, Jacques L'helgoualc'h wrote: Denis Barbier a écrit, jeudi 29 décembre 2005, à 15:56 : On Thu, Dec 29, 2005 at 11:41:40AM +0100, Jacques L'helgoualc'h wrote: [tri lexicographique ou pas] [...] Comme ls et sort utilisent tous les deux le contenu de la variable LC_COLLATE, il est difficile d'avoir un comportement différent par défaut. D'accord. Du coup, c'est l'appel à LC_COLLATE qui me paraît douteux pour ls... quand les noms de fichiers seront en UTF-*, ce sera une autre paire de manches. Je ne comprends pas ta remarque, mais si tu as des noms de fichiers avec accents, comment voudrais-tu les voir afficher ? 1. chameau souris éléphant 2. chameau éléphant souris A priori c'est le 2e que l'on veut, c'est pourquoi utiliser LC_COLLATE pour ls est judicieux. Idem pour les majuscules, on préfère Aalto anneaux lune Lyre tmp à Aalto Lyre anneaux lune tmp (ce qui serait obtenu avec LC_COLLATE=C). Mais du coup, le résultat n'est pas toujours celui attendu, comme tu l'as montré avec mv. Honnêtement, je ne vois pas de solution qui soit intuitive pour tous ces cas de figure, c'est pourquoi il faudrait toujours utiliser les regexps en locale C. Pour reprendre ton exemple : LC_ALL=C mv -v [a-lA-L]* tmp Autre exemple rigolo, en estonien le z apparait entre le s et le t. Résultat des courses : devine ce que fait la commande echo rstuvwxyz123 | sed -e 's/[a-z]//g' en locale et_EE.UTF-8 ;) Mais là où je suis parfaitement d'accord avec toi, c'est que le point a une signification particulière dans les noms de fichiers, l'affichage des noms de fichiers devrait en tenir compte. Denis -- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Pensez à rajouter le mot ``spam'' dans vos champs From et Reply-To: To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: commande 'sort' et la localisation...
Denis Barbier a écrit, jeudi 29 décembre 2005, à 19:42 : On Thu, Dec 29, 2005 at 04:45:27PM +0100, Jacques L'helgoualc'h wrote: Denis Barbier a écrit, jeudi 29 décembre 2005, à 15:56 : On Thu, Dec 29, 2005 at 11:41:40AM +0100, Jacques L'helgoualc'h wrote: [tri lexicographique ou pas] [...] Comme ls et sort utilisent tous les deux le contenu de la variable LC_COLLATE, il est difficile d'avoir un comportement différent par défaut. D'accord. Du coup, c'est l'appel à LC_COLLATE qui me paraît douteux pour ls... quand les noms de fichiers seront en UTF-*, ce sera une autre paire de manches. Je ne comprends pas ta remarque, Eh bien, ls devrait d'abord choisir une option qui tient compte des points, soulignés et tirets, avant de se soucier de la cédille... mais si tu as des noms de fichiers avec accents, C'est bientôt vendredi :) --- Je n'en ai pas ! C'est Mal©. Sérieusement, je pense qu'un nom de fichier est un identificateur technique, qu'il vaudrait mieux limiter aux caractères ascii imprimables au sens strict (pour éviter SPCSPCSPCTAB, et autre ^G). Qu'on y ajoute une courte description dans la langue de l'utilisateur, pourquoi pas, mais que ce soit cette chaîne l'unique clef d'accès, c'est aller vers les ennuis. Après l'UTF-* (donc les idéogrammes), on va y ajouter les panneaux routiers et des icônes *.jpeg pour les analphabètes ? (si ça se trouve, l'idée est déjà brevetée). comment voudrais-tu les voir afficher ? 1. chameau souris éléphant 2. chameau éléphant souris A priori c'est le 2e que l'on veut, c'est pourquoi utiliser LC_COLLATE pour ls est judicieux. Bon, oui, pourquoi pas... Idem pour les majuscules, on préfère Aalto anneaux lune Lyre tmp à Aalto Lyre anneaux lune tmp Ah, là j'aime autant le second, qui permet de marquer l'importance. (il me semble que c'était réglable quelque part (emacs ? (dired ?))). (ce qui serait obtenu avec LC_COLLATE=C). Mais du coup, le résultat n'est pas toujours celui attendu, comme tu l'as montré avec mv. Honnêtement, je ne vois pas de solution qui soit intuitive pour tous ces cas de figure, c'est pourquoi il faudrait toujours utiliser les regexps en locale C. Pour reprendre ton exemple : LC_ALL=C mv -v [a-lA-L]* tmp En outre, il ne me semble pas trop cohérent de ne tenir compte de la casse que dans certains cas : [a-c] != [abc] ... Autre exemple rigolo, en estonien le z apparait entre le s et le t. Résultat des courses : devine ce que fait la commande echo rstuvwxyz123 | sed -e 's/[a-z]//g' en locale et_EE.UTF-8 ;) Résultat, des erreurs incompréhensibles pour les étrangers, des scripts qui n'échouent que dans certaines régions, etc. Mais là où je suis parfaitement d'accord avec toi, c'est que le point a une signification particulière dans les noms de fichiers, l'affichage des noms de fichiers devrait en tenir compte. Merci. -- Jacques L'helgoualc'h -- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Pensez à rajouter le mot ``spam'' dans vos champs From et Reply-To: To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: commande 'sort' et la localisation...
On Wed, Dec 21, 2005 at 10:17:44AM +0100, Jacques L'helgoualc'h wrote: Frédéric BOITEUX a écrit, mercredi 21 décembre 2005, à 07:51 : Le mar 20 déc 2005 18:04:05 CET, Denis Barbier [EMAIL PROTECTED] a écrit : [...] Oui, plus exactement dans /usr/share/i18n/locales/fr_FR Quand tu compiles une locale [EMAIL PROTECTED] ou fr_FR.UTF-8, ce fichier et d'autres dans /usr/share/i18n sont lus et génèrent une version compilée dans /usr/lib/locale/ qui peut être utilisée par les fonctions de la libc. Si tu édites ce fichier, tu vois que la section LC_COLLATE ne fait que copier la même section dans /usr/share/i18n/locales/iso14651_t1 Le caractère # est U0023 IGNORE;IGNORE;IGNORE;U0023 # 91 # Ok, merci de l'info, ce n'était pas évident à trouver (j'avais trouvé ce fichier... dans ta doc !), mais son interprétation n'est pas évidente ! Elle n'explique pas la différence de comportement de sort (et ls) quand on bascule entre fr_FR et fr_BE (qui charge la /même/ définition). S'il y a des différences, c'est qu'une des locales a été correctement générée et l'autre non, cette dernière utilise alors la locale C. Denis -- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Pensez à rajouter le mot ``spam'' dans vos champs From et Reply-To: To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: commande 'sort' et la localisation...
Denis Barbier a écrit, mercredi 28 décembre 2005, à 19:40 :
On Wed, Dec 21, 2005 at 10:17:44AM +0100, Jacques L'helgoualc'h wrote:
[...]
Elle n'explique pas la différence de comportement de sort (et ls) quand
on bascule entre fr_FR et fr_BE (qui charge la /même/ définition).
S'il y a des différences, c'est qu'une des locales a été correctement
générée et l'autre non, cette dernière utilise alors la locale C.
Ah, OK, merci.
Ce qui me gêne là-dedans, c'est de voir que « sort = sort -d » en
français, sans pouvoir le désactiver pour l'affichage des répertoires...
Outre l'exemple foo.{aux,tex} + foobar.{aux,tex} --- le point est tout
de même assez courant dans les noms de fichiers --- j'ai aussi ça :
.tmp $ ls -l
total 8
-rw-r--r-- 1 lhh lhh 0 2005-12-28 23:15 Aalto
-rw-r--r-- 1 lhh lhh 0 2005-12-28 23:15 anneaux
-rw-r--r-- 1 lhh lhh 0 2005-12-28 23:15 lune
-rw-r--r-- 1 lhh lhh 0 2005-12-28 23:15 Lyre
drwxr-xr-x 2 lhh lhh 4096 2005-12-28 23:19 tmp
.tmp $ mv -v [a-l]* tmp/
`Aalto' - `tmp/Aalto'
`anneaux' - `tmp/anneaux'
`lune' - `tmp/lune'
.tmp $ ls -l
total 8
-rw-r--r-- 1 lhh lhh 0 2005-12-28 23:15 Lyre
drwxr-xr-x 2 lhh lhh 4096 2005-12-28 23:20 tmp
Pourquoi Aalto bouge-t-il, et pas Lyre ? Comme comportement /par
défaut/, ça me paraît incohérent...
--
Jacques L'helgoualc'h
--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs From et Reply-To:
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: commande 'sort' et la localisation...
On Wed, Dec 28, 2005 at 11:34:26PM +0100, Jacques L'helgoualc'h wrote: .tmp $ mv -v [a-l]* tmp/ `Aalto' - `tmp/Aalto' `anneaux' - `tmp/anneaux' `lune' - `tmp/lune' .tmp $ ls -l total 8 -rw-r--r-- 1 lhh lhh 0 2005-12-28 23:15 Lyre drwxr-xr-x 2 lhh lhh 4096 2005-12-28 23:20 tmp Pourquoi Aalto bouge-t-il, et pas Lyre ? Comme comportement /par défaut/, ça me paraît incohérent... En gros, c'est parce que l'ordre est a A b B c C ... k K l L m M ... Donc A est entre a et l, mais pas L. En pratique, tu peux utiliser LC_COLLATE=C, il est très rare d'avoir besoin du tri lexicographique. Denis -- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Pensez à rajouter le mot ``spam'' dans vos champs From et Reply-To: To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: commande 'sort' et la localisation...
Frédéric BOITEUX a écrit, mercredi 21 décembre 2005, à 07:51 : Le mar 20 déc 2005 18:04:05 CET, Denis Barbier [EMAIL PROTECTED] a écrit : [...] Oui, plus exactement dans /usr/share/i18n/locales/fr_FR Quand tu compiles une locale [EMAIL PROTECTED] ou fr_FR.UTF-8, ce fichier et d'autres dans /usr/share/i18n sont lus et génèrent une version compilée dans /usr/lib/locale/ qui peut être utilisée par les fonctions de la libc. Si tu édites ce fichier, tu vois que la section LC_COLLATE ne fait que copier la même section dans /usr/share/i18n/locales/iso14651_t1 Le caractère # est U0023 IGNORE;IGNORE;IGNORE;U0023 # 91 # Ok, merci de l'info, ce n'était pas évident à trouver (j'avais trouvé ce fichier... dans ta doc !), mais son interprétation n'est pas évidente ! Elle n'explique pas la différence de comportement de sort (et ls) quand on bascule entre fr_FR et fr_BE (qui charge la /même/ définition). L'option -d de sort permet d'ignorer si besoin les caractères non alphanumériques --- mais en fr_FR, ça devient systématique... -- Jacques L'helgoualc'h -- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Pensez à rajouter le mot ``spam'' dans vos champs From et Reply-To: To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
commande 'sort' et la localisation...
Bonjour, Je viens de tomber sur un fait curieux : en utilisant 'sort' sur un fichier contenant des lignes commençant par des '#', je me suis aperçu que sort les ignorait et triait ces lignes d'après les caractères qui suivent ces dièses ! Du coup, les différentes lignes commençant par ces dièses ne sont pas regroupées mais dispersées d'après leur contenu : $ echo A B C ## A ## D | sort A ## A B C ## D Ceci avec la locale française. Mais en locale US, cela donne : $ echo A B C ## A ## D | env LC_ALL=C sort ## A ## D A B C Je ne m'attendais pas à cela (j'ai mis un moment avant de comprendre que cela venait de la localisation), et surtout je n'ai rien trouvé là-dessus dans les pages de manuel de sort (en anglais ni en français...) Fred.
Re: commande 'sort' et la localisation...
2005/12/20, Frédéric BOITEUX [EMAIL PROTECTED]: Bonjour, Je viens de tomber sur un fait curieux : en utilisant 'sort' sur un fichier contenant des lignes commençant par des '#', je me suis aperçu que sort les ignorait et triait ces lignes d'après les caractères qui suivent ces dièses ! [...] Je ne m'attendais pas à cela (j'ai mis un moment avant de comprendre que cela venait de la localisation), et surtout je n'ai rien trouvé là-dessus dans les pages de manuel de sort (en anglais ni en français...) de mémoire, je dirai que les pages de manuel ne sont pas à jour... tu retrouves ces problèmes avec ls, etc. (en fait tous les outils GNU). Je crois que c'est documenté dans la libc... Désolé pour les imprécisions : c'est tout de mémoire... PK -- |\ _,,,---,,_ Patrice KARATCHENTZEFF ZZZzz /,`.-'`'-. ;-;;,_ mailto:[EMAIL PROTECTED] |,4- ) )-,_. ,\ ( `'-' http://p.karatchentzeff.free.fr '---''(_/--' `-'\_)
Re: commande 'sort' et la localisation...
Le mar 20 déc 2005 14:10:03 CET, Patrice Karatchentzeff [EMAIL PROTECTED] a écrit : de mémoire, je dirai que les pages de manuel ne sont pas à jour... tu retrouves ces problèmes avec ls, etc. (en fait tous les outils GNU). Je crois que c'est documenté dans la libc... Désolé pour les imprécisions : c'est tout de mémoire... Salut Patrice, Merci de l'info, on en parle un peu effectivement dans la doc de la libc... Il semble que ce soit la définition des 'Collation Functions' qui entrent en jeu. Dans mon précédent exemple, il suffit de faire env LC_COLLATE=C sort pour obtenir le tri que j'attendais. Ce que je me demande, c'est comment en savoir plus sur les définitions de la localisation française (et notamment sur ces ordres de tri ...) Fred.
Re: commande 'sort' et la localisation...
Frédéric BOITEUX a écrit, mardi 20 décembre 2005, à 14:06 : Bonjour, bonjour, Je viens de tomber sur un fait curieux : en utilisant 'sort' sur un fichier contenant des lignes commençant par des '#', je me suis aperçu que sort les ignorait et triait ces lignes d'après les caractères qui suivent ces dièses ! [...] Je ne m'attendais pas à cela (j'ai mis un moment avant de comprendre que cela venait de la localisation), et surtout je n'ai rien trouvé là-dessus dans les pages de manuel de sort (en anglais ni en français...) Cf. archives DUF « Chiffres romains, locale et tri », du 19 juin 2005. ça m'agace aussi pour ls : $ ls -1 foo* foo.aux foobar.aux foobar.dvi foobar.tex foo.dvi foo.tex En passant en locale belge ou suisse ça ne le fait plus... -- Jacques L'helgoualc'h -- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Pensez à rajouter le mot ``spam'' dans vos champs From et Reply-To: To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: commande 'sort' et la localisation...
On Tue, Dec 20, 2005 at 02:17:17PM +0100, Frédéric BOITEUX wrote: Le mar 20 déc 2005 14:10:03 CET, Patrice Karatchentzeff [EMAIL PROTECTED] a écrit : de mémoire, je dirai que les pages de manuel ne sont pas à jour... tu retrouves ces problèmes avec ls, etc. (en fait tous les outils GNU). Je crois que c'est documenté dans la libc... Désolé pour les imprécisions : c'est tout de mémoire... Salut Patrice, Merci de l'info, on en parle un peu effectivement dans la doc de la libc... Il semble que ce soit la définition des 'Collation Functions' qui entrent en jeu. Dans mon précédent exemple, il suffit de faire env LC_COLLATE=C sort pour obtenir le tri que j'attendais. Ce que je me demande, c'est comment en savoir plus sur les définitions de la localisation française (et notamment sur ces ordres de tri ...) La dernière partie de mon exposé lors de debconf5 donne les principes de base http://people.debian.org/~barbier/talks/debconf5/glibc-locale.pdf Denis -- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Pensez à rajouter le mot ``spam'' dans vos champs From et Reply-To: To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: commande 'sort' et la localisation...
Le mar 20 déc 2005 15:40:25 CET, Denis Barbier [EMAIL PROTECTED] a écrit : La dernière partie de mon exposé lors de debconf5 donne les principes de base http://people.debian.org/~barbier/talks/debconf5/glibc-locale.pdf Merci, cela a l'air bien intéressant et demande un examen approfondi, mais ce que je me demandais, c'est s'il y a une commande qui indique *comment* est faite la locate courante : ce qu'elle « contient » ? quels sont définitions utilisées ? Mais peut-être est-ce seulement dans le source de la libc ? Fred.
Re: commande 'sort' et la localisation...
On Tue, Dec 20, 2005 at 03:59:30PM +0100, Frédéric BOITEUX wrote: Le mar 20 déc 2005 15:40:25 CET, Denis Barbier [EMAIL PROTECTED] a écrit : La dernière partie de mon exposé lors de debconf5 donne les principes de base http://people.debian.org/~barbier/talks/debconf5/glibc-locale.pdf Merci, cela a l'air bien intéressant et demande un examen approfondi, mais ce que je me demandais, c'est s'il y a une commande qui indique *comment* est faite la locate courante : ce qu'elle « contient » ? La commande locale permet de récupérer beaucoup d'informations, mais pas celles concernant LC_COLLATE. quels sont définitions utilisées ? Mais peut-être est-ce seulement dans le source de la libc ? Oui, plus exactement dans /usr/share/i18n/locales/fr_FR Quand tu compiles une locale [EMAIL PROTECTED] ou fr_FR.UTF-8, ce fichier et d'autres dans /usr/share/i18n sont lus et génèrent une version compilée dans /usr/lib/locale/ qui peut être utilisée par les fonctions de la libc. Si tu édites ce fichier, tu vois que la section LC_COLLATE ne fait que copier la même section dans /usr/share/i18n/locales/iso14651_t1 Le caractère # est U0023 IGNORE;IGNORE;IGNORE;U0023 # 91 # ce qui implique qu'il n'intervient que dans les comparaisons de 4e niveau. Mais tu devrais commencer par lire le document ci-dessus ;) Denis -- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Pensez à rajouter le mot ``spam'' dans vos champs From et Reply-To: To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: commande 'sort' et la localisation...
Le mar 20 déc 2005 18:04:05 CET, Denis Barbier [EMAIL PROTECTED] a écrit : La commande locale permet de récupérer beaucoup d'informations, mais pas celles concernant LC_COLLATE. oui, c'est la seule fonction que je connaissais. Oui, plus exactement dans /usr/share/i18n/locales/fr_FR Quand tu compiles une locale [EMAIL PROTECTED] ou fr_FR.UTF-8, ce fichier et d'autres dans /usr/share/i18n sont lus et génèrent une version compilée dans /usr/lib/locale/ qui peut être utilisée par les fonctions de la libc. Si tu édites ce fichier, tu vois que la section LC_COLLATE ne fait que copier la même section dans /usr/share/i18n/locales/iso14651_t1 Le caractère # est U0023 IGNORE;IGNORE;IGNORE;U0023 # 91 # Ok, merci de l'info, ce n'était pas évident à trouver (j'avais trouvé ce fichier... dans ta doc !), mais son interprétation n'est pas évidente ! ce qui implique qu'il n'intervient que dans les comparaisons de 4e niveau. Mais tu devrais commencer par lire le document ci-dessus ;) J'ai déjà commencé, et je le lirai sûrement en entier quand j'aurai un moment de libre ! Merci et bonne journée, Fred.
