Discussion :

[Liamm]

Bonjour,

2 questions sur les variables d'environnement du Shell :

Q1 / Où se trouvent les variables (d'environnement) LC_NUMERIC et LC_CTYPE ?
et
Q2 / Quelles sont les valeurs possibles à attribuer à ces deux variables ?

[disedorgue]

Alors, au plus simple, je te suggère la lecture d'au moins des man locale section 1 et 5 ainsi que de localdef.

[Invité]

Q3. combien tu nous donnes pour faire tes devoirs ?

[Liamm]

1/ Quand je tape :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

$ man locale

j'obtiens local(1). Comment obtenir local(5) ?

2/

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

$ man localdef  #ne marche pas

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

$ man localedef #marche

[Liamm]

@N_BaH Ma considération !

[al1_24]

1/ Quand je tape :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

$ man locale

j'obtiens local(1). Comment obtenir local(5) ?

En commençant par man man

[Liamm]

En fait, la question finale à laquelle je cherche une réponse est :

Comment utiliser la commande sort du shell pour trier des valeurs numériques avec des séparateurs pour les milliers (espace non sécable) ?

Et je sens que la solution est par là :

LC_NUMERIC
The definition starts with the string LC_NUMERIC in the first column.

The following keywords are allowed:

decimal_point
followed by the string that will be used as the decimal
delimiter when formatting numeric quantities.

thousands_sep
followed by the string that will be used as a group separator
when formatting numeric quantities.

. . .

[Invité]

hmmm, je ne suis pas convaincu : ce sont des définitions globales pour le système entier.
je ne vois pas comment définir thousands_sep en exportant LC_NUMERIC.

[disedorgue]

En fait, il y a un bug dans le cas des locales qui prennent des séparateurs sur plusieurs octets...

Par exemple, la locale fr_FR.utf8 utilise comme thousands_sep le narrow nobreak space (\xe2\x80\xaf) et avec celle-ci, pas moyen de trier des nombres avec les séparateurs.

Par contre, si on utilise par exemple la locale en_US.utf8 qui a comme séparateur de centaine la virgule et le point comme séparateur décimale, cela fonctionne:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
$ locale
LANG=fr_FR.UTF-8
LANGUAGE=
LC_CTYPE="en_US.utf8"
LC_NUMERIC="en_US.utf8"
LC_TIME="en_US.utf8"
LC_COLLATE="en_US.utf8"
LC_MONETARY="en_US.utf8"
LC_MESSAGES="en_US.utf8"
LC_PAPER="en_US.utf8"
LC_NAME="en_US.utf8"
LC_ADDRESS="en_US.utf8"
LC_TELEPHONE="en_US.utf8"
LC_MEASUREMENT="en_US.utf8"
LC_IDENTIFICATION="en_US.utf8"
LC_ALL=en_US.utf8
$ echo -e '20100\n20,000' |  sort -h
20,000
20100
$ echo -e '20100\n20,100' |  sort -h
20,100
20100
$ echo -e '20100\n20,100.1' |  sort -h
20100
20,100.1
$ echo -e '20100.2\n20,100.1' |  sort -h
20,100.1
20100.2

[Liamm]

Merci disedorgue,

C'est gênant ce bug.
Et c'est étonnant qu'il ne soit pas corrigé depuis le temps.

Que peut-on avoir dans une zone "numérique" ?
=> des chiffres, des séparateurs pour les décimales variant suivant les pays, des séparateurs pour les milliers variant suivant les pays,les signes + et -, des espaces précédant la valeur numérique, et (mais ce n'est pas trop recommandé) des sigles comme $,€ variant suivant les pays.

On peut voir ce bug lié aux variables locales ou à la commande sort, qui ne prend pas en compte les variables locales.

Ne pourrait-on pas imaginer une commande sort qui en plus des options -n -g -h possède une option pour gérer le cas de ces séparateurs de milliers ?

NB : Chez moi le "no break space" en UTF-8 correspond non pas à (\xe2\x80\xaf) mais à (\xc2\xa0)

[disedorgue]

Ce n'est pas sort le problème, c'est la libc je pense avec les appels strcoll et autre...

Sinon, tu confonds entre le "no-break space" (c2a0) et le "narrow no-break space" (e280af) :
https://www.fileformat.info/info/uni...202f/index.htm
https://www.fileformat.info/info/uni...00a0/index.htm

Et donc, même si pas de bug, la solution avec la locale ne fonctionnerait pas dans ton cas puisque toi, tu veux le "no-break space"

Pour la commande sort, tu peux toujours faire une proposition d'évolution aux concepteurs, s'ils y trouvent un intérêt, il pourraient le prendre en considération dans le futur...

[Flodelarab]

Bonjour

Tu touches là la différence entre l'idéal et la réalité. Dans l'idéal, on pourrait mettre n'importe quel caractère dans les noms de fichiers. Mais si on met des espaces, certains scripts mal-faits vont planter; d'autres fichiers avec des caractères UTF8 exotiques idem (⛪). Dominos Pizza a eu un bug, largement relayé par la presse, car les adresses françaises contenaient une apostrophe, ce qui devait faire sortir de la chaîne de caractère et plantait le "GPS".

L'espace insécable ne fait pas appel au nombre mais à l'écriture du nombre. Tu voudrais donc trier une écriture comme un nombre. La technique est celle donnée dans l'autre discussion. Pardon d'insister. Il faut transformer l'écriture en nombre pour la traiter.
Là où je te comprends, c'est que l'espace insécable est intéressante principalement pour les nombres et les ponctuations. Donc ce n'est pas élégant d'avoir à transformer. Mais ta donnée n'est pas considérée numérique et il va passer de l'eau sous les ponts avant qu'elle le soit.