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 ?
La locale FR doit indiquer l'espace comme separateur de milliers (ce qui est bien conforme aux usages). sort se comporte bien conformement a la spec qui indique que le champs doit prendre en compte le separateur de millier, le bug a mon avis est dans la spec qui devrait faire un cas particulier pour l'espace -- ou meme supprimer completement la dependance sur le separateur de milliers, il y a une raison pour laquelle on ne l'utilise pas dans le formatage normal des nombres ni en lecture dans les fonctions standards...
A+
-- Jean-Marc Site de usenet-fr: http://www.usenet-fr.news.eu.org
François Meyer <nobody@nowhere.invalid> writes:
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 ?
La locale FR doit indiquer l'espace comme separateur de milliers (ce qui
est bien conforme aux usages). sort se comporte bien conformement a la
spec qui indique que le champs doit prendre en compte le separateur de
millier, le bug a mon avis est dans la spec qui devrait faire un cas
particulier pour l'espace -- ou meme supprimer completement la dependance
sur le separateur de milliers, il y a une raison pour laquelle on ne
l'utilise pas dans le formatage normal des nombres ni en lecture dans les
fonctions standards...
A+
--
Jean-Marc
Site de usenet-fr: http://www.usenet-fr.news.eu.org
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 ?
La locale FR doit indiquer l'espace comme separateur de milliers (ce qui est bien conforme aux usages). sort se comporte bien conformement a la spec qui indique que le champs doit prendre en compte le separateur de millier, le bug a mon avis est dans la spec qui devrait faire un cas particulier pour l'espace -- ou meme supprimer completement la dependance sur le separateur de milliers, il y a une raison pour laquelle on ne l'utilise pas dans le formatage normal des nombres ni en lecture dans les fonctions standards...
A+
-- Jean-Marc Site de usenet-fr: http://www.usenet-fr.news.eu.org
Nicolas George
Jean-Marc Bourguet wrote in message :
le bug a mon avis est dans la spec
Il n'y a pas de bug ! Le comportement est tel que désiré par le principe de la localisation. À chacun de voir s'il veut localiser ou pas.
Jean-Marc Bourguet wrote in message
<pxbr66j1seh.fsf@news.bourguet.org>:
le bug a mon avis est dans la spec
Il n'y a pas de bug ! Le comportement est tel que désiré par le principe de
la localisation. À chacun de voir s'il veut localiser ou pas.
À (at) 14 Oct 2008 08:13:04 GMT, François Meyer écrivait (wrote):
Bon et on peut remonter à quelqu'un le comportement aberrant du "localisateur" fr quant aux espaces dans les nombres ?
Ce n'est pas un bug. C'est normal. De toutes manières, utiliser l'espace comme séparateur, c'est idiot. Il vaut mieux une tabulation. ;-)
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Vincent Lefevre
Dans l'article , Jean-Marc Bourguet écrit:
La locale FR doit indiquer l'espace comme separateur de milliers (ce qui est bien conforme aux usages). sort se comporte bien conformement a la spec qui indique que le champs doit prendre en compte le separateur de millier,
Oui, on retrouve le même comportement en remplaçant l'espace par une virgule et en utilisant LANG=en_US.
le bug a mon avis est dans la spec qui devrait faire un cas particulier pour l'espace -- ou meme supprimer completement la dependance sur le separateur de milliers, il y a une raison pour laquelle on ne l'utilise pas dans le formatage normal des nombres ni en lecture dans les fonctions standards...
C'est plutôt à l'utilisateur de faire attention aux locales qu'il utilise. Les nombres avec séparateur des milliers auraient pu être sortis par un printf avec le flag ' auquel cas il est important de prendre en compte le séparateur des milliers. De toute façon on ne peut pas changer: POSIX dit bien:
-n Restrict the sort key to an initial numeric string, consisting of optional <blank>s, optional minus sign, and zero or more digits with an optional radix character and thousands separators (as defined in the current locale), which shall be sorted by arithmetic value. An empty digit string shall be treated as zero. Leading zeros and signs on zeros shall not affect ordering.
Maintenant, ça me semble ambigu: le séparateur des milliers doit-il se trouver forcément aux positions indiquées par le champ "grouping" de la locale, ou bien peut-il se trouver un peu partout, comme sur l'exemple donné dans cette enfilade? Il semble que sa position soit ignorée, mais est-ce que ce comportement est spécifié quelque part?
Dans l'article <pxbr66j1seh.fsf@news.bourguet.org>,
Jean-Marc Bourguet <jm@bourguet.org> écrit:
La locale FR doit indiquer l'espace comme separateur de milliers (ce qui
est bien conforme aux usages). sort se comporte bien conformement a la
spec qui indique que le champs doit prendre en compte le separateur de
millier,
Oui, on retrouve le même comportement en remplaçant l'espace par une
virgule et en utilisant LANG=en_US.
le bug a mon avis est dans la spec qui devrait faire un cas
particulier pour l'espace -- ou meme supprimer completement la
dependance sur le separateur de milliers, il y a une raison pour
laquelle on ne l'utilise pas dans le formatage normal des nombres ni
en lecture dans les fonctions standards...
C'est plutôt à l'utilisateur de faire attention aux locales qu'il
utilise. Les nombres avec séparateur des milliers auraient pu être
sortis par un printf avec le flag ' auquel cas il est important de
prendre en compte le séparateur des milliers. De toute façon on ne
peut pas changer: POSIX dit bien:
-n
Restrict the sort key to an initial numeric string, consisting of
optional <blank>s, optional minus sign, and zero or more digits
with an optional radix character and thousands separators (as
defined in the current locale), which shall be sorted by
arithmetic value. An empty digit string shall be treated as zero.
Leading zeros and signs on zeros shall not affect ordering.
Maintenant, ça me semble ambigu: le séparateur des milliers doit-il
se trouver forcément aux positions indiquées par le champ "grouping"
de la locale, ou bien peut-il se trouver un peu partout, comme sur
l'exemple donné dans cette enfilade? Il semble que sa position soit
ignorée, mais est-ce que ce comportement est spécifié quelque part?
La locale FR doit indiquer l'espace comme separateur de milliers (ce qui est bien conforme aux usages). sort se comporte bien conformement a la spec qui indique que le champs doit prendre en compte le separateur de millier,
Oui, on retrouve le même comportement en remplaçant l'espace par une virgule et en utilisant LANG=en_US.
le bug a mon avis est dans la spec qui devrait faire un cas particulier pour l'espace -- ou meme supprimer completement la dependance sur le separateur de milliers, il y a une raison pour laquelle on ne l'utilise pas dans le formatage normal des nombres ni en lecture dans les fonctions standards...
C'est plutôt à l'utilisateur de faire attention aux locales qu'il utilise. Les nombres avec séparateur des milliers auraient pu être sortis par un printf avec le flag ' auquel cas il est important de prendre en compte le séparateur des milliers. De toute façon on ne peut pas changer: POSIX dit bien:
-n Restrict the sort key to an initial numeric string, consisting of optional <blank>s, optional minus sign, and zero or more digits with an optional radix character and thousands separators (as defined in the current locale), which shall be sorted by arithmetic value. An empty digit string shall be treated as zero. Leading zeros and signs on zeros shall not affect ordering.
Maintenant, ça me semble ambigu: le séparateur des milliers doit-il se trouver forcément aux positions indiquées par le champ "grouping" de la locale, ou bien peut-il se trouver un peu partout, comme sur l'exemple donné dans cette enfilade? Il semble que sa position soit ignorée, mais est-ce que ce comportement est spécifié quelque part?
> La locale FR doit indiquer l'espace comme separateur de milliers (ce qui > est bien conforme aux usages). sort se comporte bien conformement a la > spec qui indique que le champs doit prendre en compte le separateur de > millier,
Oui, on retrouve le même comportement en remplaçant l'espace par une virgule et en utilisant LANG=en_US.
> le bug a mon avis est dans la spec qui devrait faire un cas particulier > pour l'espace -- ou meme supprimer completement la dependance sur le > separateur de milliers, il y a une raison pour laquelle on ne l'utilise > pas dans le formatage normal des nombres ni en lecture dans les > fonctions standards...
C'est plutôt à l'utilisateur de faire attention aux locales qu'il utilise.
Je serais plutot d'avis que c'est au programme a considerer l'effet des locales pour la definition des formats qu'il accepte, quite a changer la locale au moment de ses IO si l'effet est indesirable.
Je suis loin d'etre sur que la spec a ete concue en ayant considere les locales qui ont l'espace comme separateur de milliers.
Les nombres avec séparateur des milliers auraient pu être sortis par un printf avec le flag ' auquel cas il est important de prendre en compte le séparateur des milliers.
L'utilisation de ce flag pour quelque chose qui doit etre relu par une machine ne me semble purement et simplement pas adapte.
De toute façon on ne peut pas changer: POSIX dit bien:
C'est ce a quoi je faisais reference en disant que le comportement etait conforme a la spec. (Et je n'ai pas d'opinion tranchee sur le fait que la changer soit desirable ou non...)
A+
-- Jean-Marc Site de usenet-fr: http://www.usenet-fr.news.eu.org
Vincent Lefevre <vincent+news@vinc17.org> writes:
Dans l'article <pxbr66j1seh.fsf@news.bourguet.org>,
Jean-Marc Bourguet <jm@bourguet.org> écrit:
> La locale FR doit indiquer l'espace comme separateur de milliers (ce qui
> est bien conforme aux usages). sort se comporte bien conformement a la
> spec qui indique que le champs doit prendre en compte le separateur de
> millier,
Oui, on retrouve le même comportement en remplaçant l'espace par une
virgule et en utilisant LANG=en_US.
> le bug a mon avis est dans la spec qui devrait faire un cas particulier
> pour l'espace -- ou meme supprimer completement la dependance sur le
> separateur de milliers, il y a une raison pour laquelle on ne l'utilise
> pas dans le formatage normal des nombres ni en lecture dans les
> fonctions standards...
C'est plutôt à l'utilisateur de faire attention aux locales qu'il
utilise.
Je serais plutot d'avis que c'est au programme a considerer l'effet des
locales pour la definition des formats qu'il accepte, quite a changer la
locale au moment de ses IO si l'effet est indesirable.
Je suis loin d'etre sur que la spec a ete concue en ayant considere les
locales qui ont l'espace comme separateur de milliers.
Les nombres avec séparateur des milliers auraient pu être sortis
par un printf avec le flag ' auquel cas il est important de prendre en
compte le séparateur des milliers.
L'utilisation de ce flag pour quelque chose qui doit etre relu par une
machine ne me semble purement et simplement pas adapte.
De toute façon on ne peut pas changer: POSIX dit bien:
C'est ce a quoi je faisais reference en disant que le comportement etait
conforme a la spec. (Et je n'ai pas d'opinion tranchee sur le fait que la
changer soit desirable ou non...)
A+
--
Jean-Marc
Site de usenet-fr: http://www.usenet-fr.news.eu.org
> La locale FR doit indiquer l'espace comme separateur de milliers (ce qui > est bien conforme aux usages). sort se comporte bien conformement a la > spec qui indique que le champs doit prendre en compte le separateur de > millier,
Oui, on retrouve le même comportement en remplaçant l'espace par une virgule et en utilisant LANG=en_US.
> le bug a mon avis est dans la spec qui devrait faire un cas particulier > pour l'espace -- ou meme supprimer completement la dependance sur le > separateur de milliers, il y a une raison pour laquelle on ne l'utilise > pas dans le formatage normal des nombres ni en lecture dans les > fonctions standards...
C'est plutôt à l'utilisateur de faire attention aux locales qu'il utilise.
Je serais plutot d'avis que c'est au programme a considerer l'effet des locales pour la definition des formats qu'il accepte, quite a changer la locale au moment de ses IO si l'effet est indesirable.
Je suis loin d'etre sur que la spec a ete concue en ayant considere les locales qui ont l'espace comme separateur de milliers.
Les nombres avec séparateur des milliers auraient pu être sortis par un printf avec le flag ' auquel cas il est important de prendre en compte le séparateur des milliers.
L'utilisation de ce flag pour quelque chose qui doit etre relu par une machine ne me semble purement et simplement pas adapte.
De toute façon on ne peut pas changer: POSIX dit bien:
C'est ce a quoi je faisais reference en disant que le comportement etait conforme a la spec. (Et je n'ai pas d'opinion tranchee sur le fait que la changer soit desirable ou non...)
A+
-- Jean-Marc Site de usenet-fr: http://www.usenet-fr.news.eu.org
Vincent Lefevre
Dans l'article , Jean-Marc Bourguet écrit:
Vincent Lefevre <vincent+ writes:
> C'est plutôt à l'utilisateur de faire attention aux locales qu'il > utilise.
Je serais plutot d'avis que c'est au programme a considerer l'effet des locales pour la definition des formats qu'il accepte, quite a changer la locale au moment de ses IO si l'effet est indesirable.
Ça dépend de quel programme on parle. Je pensais ici à l'utilisateur de l'utilitaire "sort", ou plus généralement celui qui va utiliser une commande/fonction/etc. dont le comportement va dépendre des locales.
Dans l'article <pxbiqrv1m0g.fsf@news.bourguet.org>,
Jean-Marc Bourguet <jm@bourguet.org> écrit:
Vincent Lefevre <vincent+news@vinc17.org> writes:
> C'est plutôt à l'utilisateur de faire attention aux locales qu'il
> utilise.
Je serais plutot d'avis que c'est au programme a considerer l'effet des
locales pour la definition des formats qu'il accepte, quite a changer la
locale au moment de ses IO si l'effet est indesirable.
Ça dépend de quel programme on parle. Je pensais ici à l'utilisateur
de l'utilitaire "sort", ou plus généralement celui qui va utiliser une
commande/fonction/etc. dont le comportement va dépendre des locales.
> C'est plutôt à l'utilisateur de faire attention aux locales qu'il > utilise.
Je serais plutot d'avis que c'est au programme a considerer l'effet des locales pour la definition des formats qu'il accepte, quite a changer la locale au moment de ses IO si l'effet est indesirable.
Ça dépend de quel programme on parle. Je pensais ici à l'utilisateur de l'utilitaire "sort", ou plus généralement celui qui va utiliser une commande/fonction/etc. dont le comportement va dépendre des locales.
Il n'y a pas de bug ! Le comportement est tel que désiré par le principe de la localisation. À chacun de voir s'il veut localiser ou pas.
J'ai toujours pensé que c'était une grosse connerie que d'avoir "localisé" la commande sort. On se serait bien mieux porté avec une commande locsort voire un sort --loc.
-- Blop
Nicolas George <nicolas$george@salle-s.org> writes:
Jean-Marc Bourguet wrote in message
<pxbr66j1seh.fsf@news.bourguet.org>:
le bug a mon avis est dans la spec
Il n'y a pas de bug ! Le comportement est tel que désiré par le principe de
la localisation. À chacun de voir s'il veut localiser ou pas.
J'ai toujours pensé que c'était une grosse connerie que d'avoir
"localisé" la commande sort. On se serait bien mieux porté avec une
commande locsort voire un sort --loc.
Il n'y a pas de bug ! Le comportement est tel que désiré par le principe de la localisation. À chacun de voir s'il veut localiser ou pas.
J'ai toujours pensé que c'était une grosse connerie que d'avoir "localisé" la commande sort. On se serait bien mieux porté avec une commande locsort voire un sort --loc.
-- Blop
Stephane CHAZELAS
2008-10-15, 17:33(+02), Be Blop:
Nicolas George <nicolas$ writes:
Jean-Marc Bourguet wrote in message :
le bug a mon avis est dans la spec
Il n'y a pas de bug ! Le comportement est tel que désiré par le principe de la localisation. À chacun de voir s'il veut localiser ou pas.
J'ai toujours pensé que c'était une grosse connerie que d'avoir "localisé" la commande sort. On se serait bien mieux porté avec une commande locsort voire un sort --loc.
Soit on localise tout, soit on ne localise rien.
C'est une "known trap" du shell scripting, pour tout ce qui est character range, sorting, messages, dates, heures... il faut se poser la question de si on veut travailler avec le format choisi par l'utilisateur ou avec un format standard.
Pour un shell interactif, l'utilisateur veut que son choix soit respecté mais le plus souvent dans un script, a part pour d'eventuelles interactions avec l'utilisateur, on travaillera avec les formats standards (ou le format qui s'applique aux donnees a manipuler). D'où le:
LC_ALL=C sort
LC_ALL=C ls -l
LC_ALL=C command eval 'case $a in ([a-z]) ;; esac' ...
-- Stéphane
2008-10-15, 17:33(+02), Be Blop:
Nicolas George <nicolas$george@salle-s.org> writes:
Jean-Marc Bourguet wrote in message
<pxbr66j1seh.fsf@news.bourguet.org>:
le bug a mon avis est dans la spec
Il n'y a pas de bug ! Le comportement est tel que désiré par le principe de
la localisation. À chacun de voir s'il veut localiser ou pas.
J'ai toujours pensé que c'était une grosse connerie que d'avoir
"localisé" la commande sort. On se serait bien mieux porté avec une
commande locsort voire un sort --loc.
Soit on localise tout, soit on ne localise rien.
C'est une "known trap" du shell scripting, pour tout ce qui est
character range, sorting, messages, dates, heures... il faut se
poser la question de si on veut travailler avec le format choisi
par l'utilisateur ou avec un format standard.
Pour un shell interactif, l'utilisateur veut que son choix soit
respecté mais le plus souvent dans un script, a part pour
d'eventuelles interactions avec l'utilisateur, on travaillera
avec les formats standards (ou le format qui s'applique aux
donnees a manipuler). D'où le:
LC_ALL=C sort
LC_ALL=C ls -l
LC_ALL=C command eval 'case $a in ([a-z]) ;; esac' ...
Il n'y a pas de bug ! Le comportement est tel que désiré par le principe de la localisation. À chacun de voir s'il veut localiser ou pas.
J'ai toujours pensé que c'était une grosse connerie que d'avoir "localisé" la commande sort. On se serait bien mieux porté avec une commande locsort voire un sort --loc.
Soit on localise tout, soit on ne localise rien.
C'est une "known trap" du shell scripting, pour tout ce qui est character range, sorting, messages, dates, heures... il faut se poser la question de si on veut travailler avec le format choisi par l'utilisateur ou avec un format standard.
Pour un shell interactif, l'utilisateur veut que son choix soit respecté mais le plus souvent dans un script, a part pour d'eventuelles interactions avec l'utilisateur, on travaillera avec les formats standards (ou le format qui s'applique aux donnees a manipuler). D'où le:
LC_ALL=C sort
LC_ALL=C ls -l
LC_ALL=C command eval 'case $a in ([a-z]) ;; esac' ...
