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
la source

Réponses:

31

Ignorer l'ordre de classement.

echo -e "c\nb\nB\na" | LC_COLLATE=C sort
Ignacio Vazquez-Abrams
la 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):

  1. echo -e "d\nD\nc\nb\nB\na" | sort
  2. echo -e "d\nD\nc\nb\nB\na" | sort --ignore-case
  3. echo -e "d\nD\nc\nb\nB\na" | LC_COLLATE=C sort
  4. 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.
la 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