GNU trié par casse

35

L' sortutilitaire dans Ubuntu 10.04 (Lucid) effectue toujours un tri sans distinction de casse, comme si vous le spécifiiez --ignore-case.

The two sort just give the same result: 

echo -e "c\nb\nB\na" | sort
echo -e "c\nb\nB\na" | sort --ignore-case

Mais parfois, je souhaite effectuer un tri en fonction de la casse, afin que les lettres majuscules viennent en premier, puis les lettres minuscules. C'est possible?

linux

— Xiè Jìléi
source

31

Ignorer l'ordre de classement.

echo -e "c\nb\nB\na" | LC_COLLATE=C sort

— Ignacio Vazquez-Abrams
source

5

Cela fonctionne, mais par définition seulement s'il n'y a pas de caractères étrangers. sont en jeu; ils trieront après les lettres ASCII 7 bits; essayez echo $'B\nÄ\nb\na' | LC_COLLATE=C sort. Le fait que GNU sortavec une non- Clocale effectue toujours un tri respectueux de la casse soit-il considéré comme un bogue ?

— mklement0

En ce qui concerne les "caractères étrangers", la C.UTF-8locale ( LC_COLLATE=C.UTF-8) effectuera un tri sensible à la casse, tout en traitant les caractères UTF-8 non ascii "normalement". Malheureusement, il n’est pas disponible en amont dans glibc et n’est corrigé que par Debian, Ubuntu et ses dérivés.

— aplaice

13

Fait intéressant, encore un autre ordre de tri est disponible comme ceci:

echo -e "c\nb\nB\na" | LC_COLLATE=C sort --ignore-case

qui met la lettre majuscule avant la lettre minuscule correspondante.

Voici une comparaison de leurs sorties (j'ai ajouté "d" et "D") dans les en_US.UTF-8paramètres régionaux (sauf en cas de substitution):

echo -e "d\nD\nc\nb\nB\na" | sort
echo -e "d\nD\nc\nb\nB\na" | sort --ignore-case
echo -e "d\nD\nc\nb\nB\na" | LC_COLLATE=C sort
echo -e "d\nD\nc\nb\nB\na" | LC_COLLATE=C sort --ignore-case

Sortie:

1   2   3   4
-   -   -   -
a   a   B   a
b   b   D   B
B   B   a   b
c   c   b   c
d   d   c   D
D   D   d   d

— En pause jusqu'à nouvel ordre.
source

Intéressant; Je constate ce comportement dans GNU sort v5.93(fourni avec OS X 10.9.3 (!)) Et v8.13, mais PAS dans v8.21et v8.22. Je suppose que les résultats de 2. et 4. peuvent toujours être considérés comme équivalents (mais cela changerait évidemment avec l'ajout de caractères étrangers).

— mklement0