Bug sur sort -k

Le
Marc Boyer
Bonjour,

je crois que j'ai trouvé un bug dans le sort de ma distribution.
Il n'utilise pas la locale de la même façon avec -k et sans.

mboyer|Experiments$ more sort-bug.csv
A 1.10
B 1.2
C 1.01
mboyer|Experiments$ echo $LANG
fr_FR.UTF-8
mboyer|Experiments$ sort -n -k2 sort-bug.csv
A 1.10
B 1.2
C 1.01
mboyer|Experiments$ cut -f2 -d sort-bug.csv | sort -n
1.01
1.10
1.2

Vous en dites quoi ?
--
"On est tout surpris, un beau soir, de trouver la satiété où
l'on cherchait le bonheur", [Beaumarchais, Mar. de Figaro, V, 7]
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Olivier Miakinen
Le #26372532
Bonjour,

Le 16/10/2015 14:39, Marc Boyer a écrit :

je crois que j'ai trouvé un bug dans le sort de ma distribution.
Il n'utilise pas la locale de la même façon avec -k et sans.

mboyer|Experiments$ more sort-bug.csv
A 1.10
B 1.2
C 1.01
mboyer|Experiments$ echo $LANG
fr_FR.UTF-8
mboyer|Experiments$ sort -n -k2 sort-bug.csv
A 1.10
B 1.2
C 1.01
mboyer|Experiments$ cut -f2 -d sort-bug.csv | sort -n
1.01
1.10
1.2

Vous en dites quoi ?



J'en dis que, du point de vue de l'option de tri « -n », toutes les
clés sont égales (à 1) quand tu es en français, avec virgule comme
séparateur décimal, le point étant donc un caractère étranger à la
clé.

Or dans le 'man' je lis :
Finalement, si toutes les clés sont égales, en dernier ressort sort
compare les lignes octet par octet suivant l’ordre défini sur la
machine. Cette dernière comparaison accepte l’option globale -r.
L’option -s (stable) inhibe cette comparaison en dernier recours afin
que les lignes considérées comme égales restent à leurs positions rela-
tives. Si aucun champ clé, et aucune option ne sont fournis, -s est
sans effet.



Mais quand tu fais un 'cut' avant le 'sort' tu changes ce que sont les
lignes complètes.

Mon conseil : si tu veux comparer avec -n des nombres avec *point*
décimal, fais « LANG=C sort -n -k2 » au lieu de « sort -n -k2 ».
Olivier Miakinen
Le #26372531
Le 16/10/2015 16:39, Olivier Miakinen a écrit :

J'en dis que, du point de vue de l'option de tri « -n », toutes les
clés sont égales (à 1) quand tu es en français, avec virgule comme
séparateur décimal, le point étant donc un caractère étranger à la
clé.

Or dans le 'man' je lis :
Finalement, si toutes les clés sont égales, en dernier ressort sort
compare les lignes octet par octet suivant l’ordre défini sur la
machine. Cette dernière comparaison accepte l’option globale -r.
L’option -s (stable) inhibe cette comparaison en dernier recours afin
que les lignes considérées comme égales restent à leurs positions rela-
tives. Si aucun champ clé, et aucune option ne sont fournis, -s est
sans effet.





La preuve :

$ cat x.csv
A 1.10
C 1.01
B 1.2

$ sort -k2 -n x.csv
A 1.10
B 1.2
C 1.01

$ sort -k2 -n -s x.csv
A 1.10
C 1.01
B 1.2
Marc Boyer
Le #26372542
Le 16-10-2015, Olivier Miakinen
Bonjour,

Le 16/10/2015 14:39, Marc Boyer a écrit :

je crois que j'ai trouvé un bug dans le sort de ma distribution.
Il n'utilise pas la locale de la même façon avec -k et sans.

mboyer|Experiments$ more sort-bug.csv
A 1.10
B 1.2
C 1.01
mboyer|Experiments$ echo $LANG
fr_FR.UTF-8
mboyer|Experiments$ sort -n -k2 sort-bug.csv
A 1.10
B 1.2
C 1.01
mboyer|Experiments$ cut -f2 -d sort-bug.csv | sort -n
1.01
1.10
1.2

Vous en dites quoi ?



J'en dis que, du point de vue de l'option de tri « -n », toutes les
clés sont égales (à 1) quand tu es en français, avec virgule comme
séparateur décimal, le point étant donc un caractère étranger à la
clé.



Je suis d'accord. Ma question (implicte je l'avoue) était
"pourquoi considère-t-il . comme séparateur décimal si
je fais un 'cut', au mépris de la locale, alors qu'il
ne le fait pas avec un -k ?

Finalement, si toutes les clés sont égales, en dernier ressort sort
compare les lignes octet par octet suivant l’ordre défini sur la
machine. Cette dernière comparaison accepte l’option globale -r.
L’option -s (stable) inhibe cette comparaison en dernier recours afin
que les lignes considérées comme égales restent à leurs positions rela-
tives. Si aucun champ clé, et aucune option ne sont fournis, -s est
sans effet.



Mais quand tu fais un 'cut' avant le 'sort' tu changes ce que sont les
lignes complètes.



oui, mais
latitude|Experiments$ sort -n -k2 -s sort-bug.csv
A 1.10
B 1.2
C 1.01

Ce qui est encore différent du cas avec cut...

Mon conseil : si tu veux comparer avec -n des nombres avec *point*
décimal, fais « LANG=C sort -n -k2 » au lieu de « sort -n -k2 ».



C'est ce que j'ai fait après avoir cherché l'heures pendant 2h.
Mais je me demandais si c'était pareil chez vous et si ça méritais
un report de bug.

Marc Boyer
--
"On est tout surpris, un beau soir, de trouver la satiété où
l'on cherchait le bonheur", [Beaumarchais, Mar. de Figaro, V, 7]
Olivier Miakinen
Le #26372544
Le 16/10/2015 17:16, Marc Boyer a écrit :

J'en dis que, du point de vue de l'option de tri « -n », toutes les
clés sont égales (à 1) quand tu es en français, avec virgule comme
séparateur décimal, le point étant donc un caractère étranger à la
clé.



Je suis d'accord. Ma question (implicte je l'avoue) était
"pourquoi considère-t-il . comme séparateur décimal si
je fais un 'cut', au mépris de la locale, alors qu'il
ne le fait pas avec un -k ?



Et la réponse est qu'il ne le considère *pas* comme séparateur
décimal. Avant le 'cut', le tri n'ayant pas pu se faire en -n
sur le deuxième champ se fait sans -n sur l'ensemble de la ligne,
donc sur "A" < "B" < "C". Après le 'cut', le tri n'ayant pas pu
se faire en -n se fait sans -n, sur les mêmes lignes puisque tu
n'as pas mis de -k.

oui, mais
latitude|Experiments$ sort -n -k2 -s sort-bug.csv
A 1.10
B 1.2
C 1.01

Ce qui est encore différent du cas avec cut...



C'est normal, puisque dans ce cas tu as "A" < "B" < "C" alors qu'avec
le 'cut' c'est "1.01" < "1.10" < "1.2" (comparaisons octet par octet
et non plus numériques).

Mon conseil : si tu veux comparer avec -n des nombres avec *point*
décimal, fais « LANG=C sort -n -k2 » au lieu de « sort -n -k2 ».



C'est ce que j'ai fait après avoir cherché l'heures pendant 2h.
Mais je me demandais si c'était pareil chez vous et si ça méritais
un report de bug.



Pas de rapport de bug : c'est le comportement documenté.
Olivier Miakinen
Le #26372548
Le 16/10/2015 18:24, J'écrivais :

oui, mais
latitude|Experiments$ sort -n -k2 -s sort-bug.csv
A 1.10
B 1.2
C 1.01

Ce qui est encore différent du cas avec cut...



C'est normal, puisque dans ce cas tu as "A" < "B" < "C" alors qu'avec
le 'cut' c'est "1.01" < "1.10" < "1.2" (comparaisons octet par octet
et non plus numériques).



Ah non, ça ce serait sans le -s. Puisque tu as ce résultat aussi
avec -s, c'est qu'au départ elles sont déjà dans cet ordre-là,
avec le A en première ligne, le B en seconde et le C en troisième.
Tu verras si tu changes l'ordre comme dans mon exemple que les
lignes ne sont pas triées, et donc tu devrais obtenir le même
ordre avec ou sans le 'cut'.
Marc Boyer
Le #26373049
Le 16-10-2015, Olivier Miakinen
C'est normal, puisque dans ce cas tu as "A" < "B" < "C" alors qu'avec
le 'cut' c'est "1.01" < "1.10" < "1.2" (comparaisons octet par octet
et non plus numériques).



Ha, c'est ça qui m'a induit en erreur, le fait que la comparaison
par octet coincide avec la comparaison numérique dans ce cas.

Merci.

Pas de rapport de bug : c'est le comportement documenté.



Très bien.

Marc Boyer
--
"On est tout surpris, un beau soir, de trouver la satiété où
l'on cherchait le bonheur", [Beaumarchais, Mar. de Figaro, V, 7]
Dominique MICOLLET
Le #26392250
Bonjour,


maitreaze78 wrote:

Le vendredi 16 Octobre 2015 à 14:39 par Marc Boyer :
je crois que j'ai trouvé un bug dans le sort de ma distribution.




....




Alors là, je n'aurais jamais pensé à faire appel à un marabout pour régler
les mauvais /sort/. :-)

Cordialement

Dominique

PS : j'ai volontairement écris sort sans s, hein :-)
Publicité
Poster une réponse
Anonyme