LC_ALL=C command eval 'case $a in ([a-z]) ;; esac' ...
A ce propos, une petite question: dans ces cas-là, y a-t-il une différence si on remplace LC_ALL=C par LANG=C ?
-- <ptilou> Mes partagaient, " Bougre de ma fatche" ...
François Meyer
Paul Gaborit wrote:
À (at) Wed, 15 Oct 2008 23:33:10 +0200, Rikishi42 écrivait (wrote):
C'est quand meme bug-ifere d'origine, non ?
Ici j'ai :
1 ubuntu 8.04.1 affectee, 2 debian 4.0 affectees,
1 debian 3.1 pas affectee, 1 rh9 pas affectee, 1 rh8 pas affectee, 1 rh7.2 pas affectee
1 SuSE 10.0 pas affectee
Solaris 2.9 est "affecté" (mais au moins c'est clairement documenté dans la page de man). Ça doit aussi être vrai pour OpenSolaris.
Dans la page de manuel j'ai :
*** WARNING *** The locale specified by the environment affects sort order. Set LC_ALL=C to get the traditional sort order that uses native byte values.
Il y a quelque chose en plus dans le man Solaris ? -- François Meyer
Paul Gaborit <Paul.Gaborit@invalid.invalid> wrote:
À (at) Wed, 15 Oct 2008 23:33:10 +0200,
Rikishi42 <skunkworks@rikishi42.net> écrivait (wrote):
C'est quand meme bug-ifere d'origine, non ?
Ici j'ai :
1 ubuntu 8.04.1 affectee,
2 debian 4.0 affectees,
1 debian 3.1 pas affectee,
1 rh9 pas affectee,
1 rh8 pas affectee,
1 rh7.2 pas affectee
1 SuSE 10.0 pas affectee
Solaris 2.9 est "affecté" (mais au moins c'est clairement documenté
dans la page de man). Ça doit aussi être vrai pour OpenSolaris.
Dans la page de manuel j'ai :
*** WARNING *** The locale specified by the environment
affects sort order. Set LC_ALL=C to get the traditional sort order that uses
native byte values.
Il y a quelque chose en plus dans le man Solaris ?
--
François Meyer
À (at) Wed, 15 Oct 2008 23:33:10 +0200, Rikishi42 écrivait (wrote):
C'est quand meme bug-ifere d'origine, non ?
Ici j'ai :
1 ubuntu 8.04.1 affectee, 2 debian 4.0 affectees,
1 debian 3.1 pas affectee, 1 rh9 pas affectee, 1 rh8 pas affectee, 1 rh7.2 pas affectee
1 SuSE 10.0 pas affectee
Solaris 2.9 est "affecté" (mais au moins c'est clairement documenté dans la page de man). Ça doit aussi être vrai pour OpenSolaris.
Dans la page de manuel j'ai :
*** WARNING *** The locale specified by the environment affects sort order. Set LC_ALL=C to get the traditional sort order that uses native byte values.
Il y a quelque chose en plus dans le man Solaris ? -- François Meyer
Paul Gaborit
À (at) 16 Oct 2008 08:55:46 GMT, François Meyer écrivait (wrote):
Paul Gaborit wrote:
Solaris 2.9 est "affecté" (mais au moins c'est clairement documenté dans la page de man). Ça doit aussi être vrai pour OpenSolaris.
Dans la page de manuel j'ai :
*** WARNING *** The locale specified by the environment affects sort order. Set LC_ALL=C to get the traditional sort order that uses native byte values.
Ah oui. J'ai la même chose. Mais c'est à la fin, après toutes les options. Je ne l'avais pas vu !
Il y a quelque chose en plus dans le man Solaris ?
-n Restricts the sort key to an initial numeric string, consisting of optional blank characters, optional minus sign, and zero or more digits with an optional radix character and thousands separators (as defined in the current locale), which will be sorted by arith- metic value. An empty digit string is treated as zero. Leading zeros and signs on zeros do not affect ordering.
Le séparateur de milliers du locale courant est donc clairement cité avec l'option -n. Et plus loin, on trouve :
LC_NUMERIC Determine the locale for the definition of the radix character and thousands separator for the -n option.
Ceci étant, la page de man sur Linux indique bien que ce n'est qu'un résumé et qu'il faut se référer à 'info sort' pour en savoir plus. ;-)
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) 16 Oct 2008 08:55:46 GMT,
François Meyer <nobody@nowhere.invalid> écrivait (wrote):
Paul Gaborit <Paul.Gaborit@invalid.invalid> wrote:
Solaris 2.9 est "affecté" (mais au moins c'est clairement documenté
dans la page de man). Ça doit aussi être vrai pour OpenSolaris.
Dans la page de manuel j'ai :
*** WARNING *** The locale specified by the environment affects
sort order. Set LC_ALL=C to get the traditional sort order that
uses native byte values.
Ah oui. J'ai la même chose. Mais c'est à la fin, après toutes les
options. Je ne l'avais pas vu !
Il y a quelque chose en plus dans le man Solaris ?
-n Restricts the sort key to an initial numeric string,
consisting of optional blank characters, optional minus sign,
and zero or more digits with an optional radix character and
thousands separators (as defined in the current locale), which
will be sorted by arith- metic value. An empty digit string
is treated as zero. Leading zeros and signs on zeros do not
affect ordering.
Le séparateur de milliers du locale courant est donc clairement cité
avec l'option -n. Et plus loin, on trouve :
LC_NUMERIC
Determine the locale for the definition of the radix
character and thousands separator for the -n option.
Ceci étant, la page de man sur Linux indique bien que ce n'est qu'un
résumé et qu'il faut se référer à 'info sort' pour en savoir plus. ;-)
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) 16 Oct 2008 08:55:46 GMT, François Meyer écrivait (wrote):
Paul Gaborit wrote:
Solaris 2.9 est "affecté" (mais au moins c'est clairement documenté dans la page de man). Ça doit aussi être vrai pour OpenSolaris.
Dans la page de manuel j'ai :
*** WARNING *** The locale specified by the environment affects sort order. Set LC_ALL=C to get the traditional sort order that uses native byte values.
Ah oui. J'ai la même chose. Mais c'est à la fin, après toutes les options. Je ne l'avais pas vu !
Il y a quelque chose en plus dans le man Solaris ?
-n Restricts the sort key to an initial numeric string, consisting of optional blank characters, optional minus sign, and zero or more digits with an optional radix character and thousands separators (as defined in the current locale), which will be sorted by arith- metic value. An empty digit string is treated as zero. Leading zeros and signs on zeros do not affect ordering.
Le séparateur de milliers du locale courant est donc clairement cité avec l'option -n. Et plus loin, on trouve :
LC_NUMERIC Determine the locale for the definition of the radix character and thousands separator for the -n option.
Ceci étant, la page de man sur Linux indique bien que ce n'est qu'un résumé et qu'il faut se référer à 'info sort' pour en savoir plus. ;-)
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
François Meyer
Paul Gaborit wrote:
À (at) 16 Oct 2008 08:55:46 GMT, François Meyer écrivait (wrote):
Paul Gaborit wrote:
Solaris 2.9 est "affecté" (mais au moins c'est clairement documenté dans la page de man). Ça doit aussi être vrai pour OpenSolaris.
Dans la page de manuel j'ai :
*** WARNING *** The locale specified by the environment affects sort order. Set LC_ALL=C to get the traditional sort order that uses native byte values.
Ah oui. J'ai la même chose. Mais c'est à la fin, après toutes les options. Je ne l'avais pas vu !
Il y a quelque chose en plus dans le man Solaris ?
-n Restricts the sort key to an initial numeric string, consisting of optional blank characters, optional minus sign, and zero or more digits with an optional radix character and thousands separators (as defined in the current locale), which will be sorted by arith- metic value. An empty digit string is treated as zero. Leading zeros and signs on zeros do not affect ordering.
Le séparateur de milliers du locale courant est donc clairement cité avec l'option -n. Et plus loin, on trouve :
LC_NUMERIC Determine the locale for the definition of the radix character and thousands separator for the -n option.
Ceci étant, la page de man sur Linux indique bien que ce n'est qu'un résumé et qu'il faut se référer à 'info sort' pour en savoir plus. ;-)
Exact. RTFI, donc. Et effectivement il y a là les mêmes infos, mais il n'est pas fait mention que les séparateurs des milliers consécutifs sont considérés comme 1 seul. Tiens ça me donne une idée, je fais un test :
Donc 1,,,,,,,,,,,,,,,,234 en locale en_GB ça fait 1234.
C'est piéju, tout de même.
Non pas que je veuille utiliser mes scripts en version localisée, mais je suis tombé là-dessus en me posant la question de ce qui se passerait si ces scripts étaient utilisés par des collègues sur des machines "localisées"...
J'en conclus qu'il faut impérativement et explicitement remettre toutes les locales à C dans ses scripts. -- François Meyer
Paul Gaborit <Paul.Gaborit@invalid.invalid> wrote:
À (at) 16 Oct 2008 08:55:46 GMT,
François Meyer <nobody@nowhere.invalid> écrivait (wrote):
Paul Gaborit <Paul.Gaborit@invalid.invalid> wrote:
Solaris 2.9 est "affecté" (mais au moins c'est clairement documenté
dans la page de man). Ça doit aussi être vrai pour OpenSolaris.
Dans la page de manuel j'ai :
*** WARNING *** The locale specified by the environment affects
sort order. Set LC_ALL=C to get the traditional sort order that
uses native byte values.
Ah oui. J'ai la même chose. Mais c'est à la fin, après toutes les
options. Je ne l'avais pas vu !
Il y a quelque chose en plus dans le man Solaris ?
-n Restricts the sort key to an initial numeric string,
consisting of optional blank characters, optional minus sign,
and zero or more digits with an optional radix character and
thousands separators (as defined in the current locale), which
will be sorted by arith- metic value. An empty digit string
is treated as zero. Leading zeros and signs on zeros do not
affect ordering.
Le séparateur de milliers du locale courant est donc clairement cité
avec l'option -n. Et plus loin, on trouve :
LC_NUMERIC
Determine the locale for the definition of the radix
character and thousands separator for the -n option.
Ceci étant, la page de man sur Linux indique bien que ce n'est qu'un
résumé et qu'il faut se référer à 'info sort' pour en savoir plus. ;-)
Exact. RTFI, donc. Et effectivement il y a là les mêmes infos,
mais il n'est pas fait mention que les séparateurs des milliers
consécutifs sont considérés comme 1 seul. Tiens ça me donne une idée,
je fais un test :
Donc 1,,,,,,,,,,,,,,,,234 en locale en_GB ça fait 1234.
C'est piéju, tout de même.
Non pas que je veuille utiliser mes scripts en version localisée,
mais je suis tombé là-dessus en me posant la question de ce qui se
passerait si ces scripts étaient utilisés par des collègues sur des
machines "localisées"...
J'en conclus qu'il faut impérativement et explicitement remettre
toutes les locales à C dans ses scripts.
--
François Meyer
À (at) 16 Oct 2008 08:55:46 GMT, François Meyer écrivait (wrote):
Paul Gaborit wrote:
Solaris 2.9 est "affecté" (mais au moins c'est clairement documenté dans la page de man). Ça doit aussi être vrai pour OpenSolaris.
Dans la page de manuel j'ai :
*** WARNING *** The locale specified by the environment affects sort order. Set LC_ALL=C to get the traditional sort order that uses native byte values.
Ah oui. J'ai la même chose. Mais c'est à la fin, après toutes les options. Je ne l'avais pas vu !
Il y a quelque chose en plus dans le man Solaris ?
-n Restricts the sort key to an initial numeric string, consisting of optional blank characters, optional minus sign, and zero or more digits with an optional radix character and thousands separators (as defined in the current locale), which will be sorted by arith- metic value. An empty digit string is treated as zero. Leading zeros and signs on zeros do not affect ordering.
Le séparateur de milliers du locale courant est donc clairement cité avec l'option -n. Et plus loin, on trouve :
LC_NUMERIC Determine the locale for the definition of the radix character and thousands separator for the -n option.
Ceci étant, la page de man sur Linux indique bien que ce n'est qu'un résumé et qu'il faut se référer à 'info sort' pour en savoir plus. ;-)
Exact. RTFI, donc. Et effectivement il y a là les mêmes infos, mais il n'est pas fait mention que les séparateurs des milliers consécutifs sont considérés comme 1 seul. Tiens ça me donne une idée, je fais un test :
Donc 1,,,,,,,,,,,,,,,,234 en locale en_GB ça fait 1234.
C'est piéju, tout de même.
Non pas que je veuille utiliser mes scripts en version localisée, mais je suis tombé là-dessus en me posant la question de ce qui se passerait si ces scripts étaient utilisés par des collègues sur des machines "localisées"...
J'en conclus qu'il faut impérativement et explicitement remettre toutes les locales à C dans ses scripts. -- François Meyer
Jean-Marc Bourguet
François Meyer writes:
J'en conclus qu'il faut impérativement et explicitement remettre toutes les locales à C dans ses scripts.
C'est ce qui a ete dit plusieurs fois :-)
(Je trouve que la maniere dont la localisation est utilisee est parfois pas reflechie(*) -- et c'est un probleme de spec --, mais meme si elle l'etait, il faudrait reflechir a la maniere dont elle doit etre utilisee dans ses scripts, donc la conclusion serait la meme: on la force a quelque chose de connu -- "C" etant vraisemblablement le choix le moins perturbant -- en dehors des cas ou on desire qu'elle soit utilisee).
-- Jean-Marc Site de usenet-fr: http://www.usenet-fr.news.eu.org
François Meyer <nobody@nowhere.invalid> writes:
J'en conclus qu'il faut impérativement et explicitement remettre
toutes les locales à C dans ses scripts.
C'est ce qui a ete dit plusieurs fois :-)
(Je trouve que la maniere dont la localisation est utilisee est parfois pas
reflechie(*) -- et c'est un probleme de spec --, mais meme si elle l'etait, il
faudrait reflechir a la maniere dont elle doit etre utilisee dans ses
scripts, donc la conclusion serait la meme: on la force a quelque chose de
connu -- "C" etant vraisemblablement le choix le moins perturbant -- en
dehors des cas ou on desire qu'elle soit utilisee).
--
Jean-Marc
Site de usenet-fr: http://www.usenet-fr.news.eu.org
J'en conclus qu'il faut impérativement et explicitement remettre toutes les locales à C dans ses scripts.
C'est ce qui a ete dit plusieurs fois :-)
(Je trouve que la maniere dont la localisation est utilisee est parfois pas reflechie(*) -- et c'est un probleme de spec --, mais meme si elle l'etait, il faudrait reflechir a la maniere dont elle doit etre utilisee dans ses scripts, donc la conclusion serait la meme: on la force a quelque chose de connu -- "C" etant vraisemblablement le choix le moins perturbant -- en dehors des cas ou on desire qu'elle soit utilisee).
-- Jean-Marc Site de usenet-fr: http://www.usenet-fr.news.eu.org
Vincent Lefevre
Dans l'article , Thierry B. écrit:
A ce propos, une petite question: dans ces cas-là, y a-t-il une différence si on remplace LC_ALL=C par LANG=C ?
Oui, si je ne me trompe pas, LC_ALL a la priorité sur les autres variables LC_*, qui ont la priorité sur LANG. En gros, LANG permet de déclarer des locales par défaut, et LC_ALL permet de forcer une locale pour l'ensemble.
Dans l'article <bi2js5-45q.ln1@prout.stex>,
Thierry B. <tth@prout.stex.invalid> écrit:
A ce propos, une petite question:
dans ces cas-là, y a-t-il une différence si on remplace
LC_ALL=C par LANG=C ?
Oui, si je ne me trompe pas, LC_ALL a la priorité sur les autres
variables LC_*, qui ont la priorité sur LANG. En gros, LANG permet
de déclarer des locales par défaut, et LC_ALL permet de forcer une
locale pour l'ensemble.
A ce propos, une petite question: dans ces cas-là, y a-t-il une différence si on remplace LC_ALL=C par LANG=C ?
Oui, si je ne me trompe pas, LC_ALL a la priorité sur les autres variables LC_*, qui ont la priorité sur LANG. En gros, LANG permet de déclarer des locales par défaut, et LC_ALL permet de forcer une locale pour l'ensemble.
