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]
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]
Le 16/10/2015 14:39, 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é.
Or dans le 'man' je lis :
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 ».
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
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 ?
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 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]
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.
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).
Pas de rapport de bug : c'est le comportement documenté.
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'.
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.
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]
maitreaze78 wrote:
....
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 :-)