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]
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
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é.
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 ».
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 ».
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 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
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.
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 16-10-2015, Olivier Miakinen <om+ a écrit :
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]
Le 16-10-2015, Olivier Miakinen <om+news@miakinen.net> a écrit :
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]
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 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é.
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é.
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 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'.
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'.
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 16-10-2015, Olivier Miakinen <om+ a écrit :
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]
Le 16-10-2015, Olivier Miakinen <om+news@miakinen.net> a écrit :
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]
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
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 :-)
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.
....
Maitre_Aze@yahoo.com
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 :-)
