C'est encore moi : Quelqu'un peut-il m'expliquer le mécanisme de ce comportement de sort :
<snip>
Juste une hypothèse : l'une des deux locales considère l'espace comme un séparateur de milliers, et pas l'autre. Du coup, pour la première, le nombre est sur tout la ligne, pour la seconde, elle ne prend que le nombre sur la première colonne.
Merci.
De rien !
'lu
François Meyer <nobody@nowhere.invalid> écrit :
C'est encore moi :
Quelqu'un peut-il m'expliquer le mécanisme de ce comportement de sort :
<snip>
Juste une hypothèse : l'une des deux locales considère l'espace comme
un séparateur de milliers, et pas l'autre. Du coup, pour la première,
le nombre est sur tout la ligne, pour la seconde, elle ne prend que le
nombre sur la première colonne.
C'est encore moi : Quelqu'un peut-il m'expliquer le mécanisme de ce comportement de sort :
<snip>
Juste une hypothèse : l'une des deux locales considère l'espace comme un séparateur de milliers, et pas l'autre. Du coup, pour la première, le nombre est sur tout la ligne, pour la seconde, elle ne prend que le nombre sur la première colonne.
Merci.
De rien !
François Meyer
Che Averell wrote:
'lu
François Meyer écrit :
C'est encore moi : Quelqu'un peut-il m'expliquer le mécanisme de ce comportement de sort :
<snip>
Juste une hypothèse : l'une des deux locales considère l'espace comme un séparateur de milliers, et pas l'autre. Du coup, pour la première, le nombre est sur tout la ligne, pour la seconde, elle ne prend que le nombre sur la première colonne.
Ça a l'air d'être ça. C'est complètement tordu :
# LC_NUMERIC=C sort -n /tmp/grumpy 2 1 3 13 2
# LC_NUMERIC=fr_FR sort -n /tmp/grumpy 13 2 2 1 3
Donc dans fr_FR, l'espace n'est pas un séparateur, il est complètement ignoré...
C'est quand même bug-ifère d'origine, non ?
Ici j'ai :
1 ubuntu 8.04.1 affectée, 2 debian 4.0 affectées,
1 debian 3.1 pas affectée, 1 rh9 pas affectée, 1 rh8 pas affectée, 1 rh7.2 pas affectée -- François Meyer
Che Averell <averell@dalton-brothers.org> wrote:
'lu
François Meyer <nobody@nowhere.invalid> écrit :
C'est encore moi :
Quelqu'un peut-il m'expliquer le mécanisme de ce comportement de sort :
<snip>
Juste une hypothèse : l'une des deux locales considère l'espace comme
un séparateur de milliers, et pas l'autre. Du coup, pour la première,
le nombre est sur tout la ligne, pour la seconde, elle ne prend que le
nombre sur la première colonne.
Ça a l'air d'être ça. C'est complètement tordu :
# LC_NUMERIC=C sort -n /tmp/grumpy
2 1 3
13 2
# LC_NUMERIC=fr_FR sort -n /tmp/grumpy
13 2
2 1 3
Donc dans fr_FR, l'espace n'est pas un séparateur,
il est complètement ignoré...
C'est quand même bug-ifère d'origine, non ?
Ici j'ai :
1 ubuntu 8.04.1 affectée,
2 debian 4.0 affectées,
1 debian 3.1 pas affectée,
1 rh9 pas affectée,
1 rh8 pas affectée,
1 rh7.2 pas affectée
--
François Meyer
C'est encore moi : Quelqu'un peut-il m'expliquer le mécanisme de ce comportement de sort :
<snip>
Juste une hypothèse : l'une des deux locales considère l'espace comme un séparateur de milliers, et pas l'autre. Du coup, pour la première, le nombre est sur tout la ligne, pour la seconde, elle ne prend que le nombre sur la première colonne.
Ça a l'air d'être ça. C'est complètement tordu :
# LC_NUMERIC=C sort -n /tmp/grumpy 2 1 3 13 2
# LC_NUMERIC=fr_FR sort -n /tmp/grumpy 13 2 2 1 3
Donc dans fr_FR, l'espace n'est pas un séparateur, il est complètement ignoré...
C'est quand même bug-ifère d'origine, non ?
Ici j'ai :
1 ubuntu 8.04.1 affectée, 2 debian 4.0 affectées,
1 debian 3.1 pas affectée, 1 rh9 pas affectée, 1 rh8 pas affectée, 1 rh7.2 pas affectée -- François Meyer
Olivier Miakinen
Le 13/10/2008 17:55, François Meyer a écrit :
[...] dans fr_FR, l'espace n'est pas un séparateur, il est complètement ignoré...
C'est quand même bug-ifère d'origine, non ?
[OUI]
Le 13/10/2008 17:55, François Meyer a écrit :
[...] dans fr_FR, l'espace n'est pas un séparateur,
il est complètement ignoré...
À (at) Mon, 13 Oct 2008 18:03:34 +0200, Olivier Miakinen <om+ écrivait (wrote):
Le 13/10/2008 17:55, François Meyer a écrit :
[...] dans fr_FR, l'espace n'est pas un séparateur, il est complètement ignoré...
C'est quand même bug-ifère d'origine, non ?
[OUI]
Ou utiliser :
sort -n -k1,1
ou :
sort -g
sort -g paraît raisonnable, mais j'ai du mal à comprendre par quel mécanisme "sort -n -k1,1" peut fonctionner là où "sort -n" échoue. Enfin bon...
Merci à tout le monde. -- François Meyer
Nicolas George
François Meyer wrote in message <48f4458e$0$31357$:
mais j'ai du mal à comprendre par quel mécanisme "sort -n -k1,1" peut fonctionner là où "sort -n" échoue.
Le découpage en champs fait par -k 1,1 se passe en premier, en utilisant l'espace comme séparateur de champ. Le résultat, c'est à dire le premier champ, est ensuite passé à la comparaison numérique. C'est cette comparaison numérique qui ignore les espaces. Mais comme il n'y a plus d'espace à cette étape...
François Meyer wrote in message
<48f4458e$0$31357$426a34cc@news.free.fr>:
mais j'ai du mal à comprendre par
quel mécanisme "sort -n -k1,1" peut fonctionner là où "sort -n" échoue.
Le découpage en champs fait par -k 1,1 se passe en premier, en utilisant
l'espace comme séparateur de champ. Le résultat, c'est à dire le premier
champ, est ensuite passé à la comparaison numérique. C'est cette comparaison
numérique qui ignore les espaces. Mais comme il n'y a plus d'espace à cette
étape...
François Meyer wrote in message <48f4458e$0$31357$:
mais j'ai du mal à comprendre par quel mécanisme "sort -n -k1,1" peut fonctionner là où "sort -n" échoue.
Le découpage en champs fait par -k 1,1 se passe en premier, en utilisant l'espace comme séparateur de champ. Le résultat, c'est à dire le premier champ, est ensuite passé à la comparaison numérique. C'est cette comparaison numérique qui ignore les espaces. Mais comme il n'y a plus d'espace à cette étape...
François Meyer
Nicolas George <nicolas$ wrote:
François Meyer wrote in message <48f4458e$0$31357$:
mais j'ai du mal à comprendre par quel mécanisme "sort -n -k1,1" peut fonctionner là où "sort -n" échoue.
Le découpage en champs fait par -k 1,1 se passe en premier, en utilisant l'espace comme séparateur de champ. Le résultat, c'est à dire le premier champ, est ensuite passé à la comparaison numérique. C'est cette comparaison numérique qui ignore les espaces. Mais comme il n'y a plus d'espace à cette étape...
sort -n passerait donc une ligne entière au comparateur qui demanderait au "localisateur" de lui fournir les champs ?
Bon et on peut remonter à quelqu'un le comportement aberrant du "localisateur" fr quant aux espaces dans les nombres ? -- François Meyer
Nicolas George <nicolas$george@salle-s.org> wrote:
François Meyer wrote in message
<48f4458e$0$31357$426a34cc@news.free.fr>:
mais j'ai du mal à comprendre par
quel mécanisme "sort -n -k1,1" peut fonctionner là où "sort -n" échoue.
Le découpage en champs fait par -k 1,1 se passe en premier, en utilisant
l'espace comme séparateur de champ. Le résultat, c'est à dire le premier
champ, est ensuite passé à la comparaison numérique. C'est cette comparaison
numérique qui ignore les espaces. Mais comme il n'y a plus d'espace à cette
étape...
sort -n passerait donc une ligne entière au comparateur qui
demanderait au "localisateur" de lui fournir les champs ?
Bon et on peut remonter à quelqu'un le comportement
aberrant du "localisateur" fr quant aux espaces dans les nombres ?
--
François Meyer
François Meyer wrote in message <48f4458e$0$31357$:
mais j'ai du mal à comprendre par quel mécanisme "sort -n -k1,1" peut fonctionner là où "sort -n" échoue.
Le découpage en champs fait par -k 1,1 se passe en premier, en utilisant l'espace comme séparateur de champ. Le résultat, c'est à dire le premier champ, est ensuite passé à la comparaison numérique. C'est cette comparaison numérique qui ignore les espaces. Mais comme il n'y a plus d'espace à cette étape...
sort -n passerait donc une ligne entière au comparateur qui demanderait au "localisateur" de lui fournir les champs ?
Bon et on peut remonter à quelqu'un le comportement aberrant du "localisateur" fr quant aux espaces dans les nombres ? -- François Meyer
