Tanto quanto eu posso dizer, a configuração da variável de ambiente LC_COLLATE=en_US.utf8
altera quatro coisas em comparação com LC_COLLATE=c
, sobre como programas como ls
classificarão arquivos:
- Os caracteres Unicode são preservados (em vez de serem substituídos por
??
garbage)
-
Acentos e sinais diacríticos não afetam a ordem de classificação
-
As diferenças entre casos não afetam a ordem de classificação
-
Caracteres de pontuação (como pontos) não afetam a ordem de classificação
A característica 1 é essencial neste dia e idade.
Os recursos 2 e 3 também são ótimos, pois tornam mais conveniente lidar com nomes de arquivos Unicode da vida real.
O recurso 4, por outro lado, é algo que eu acho realmente anti-produtivo no meu dia-a-dia, pois muitas vezes produz ordens de ordenação contra-intuitivas para nomes de arquivos Linux - onde pontos tendem a ser usados para separar sufixos ou indicar dotfiles. Eu realmente não consigo imaginar por que alguém pensou que seria uma boa idéia ignorar pontos ao classificar nomes de arquivos.
Por exemplo:
$ touch foo.txt foo2.txt foó3.txt foo4.txt
$ LC_COLLATE=en_US.utf8 ls
foo2.txt foó3.txt foo4.txt foo.txt
$ LC_COLLATE=c ls
foo.txt foo2.txt foo4.txt fo??3.txt
Nenhum é satisfatório. É assim que eu gostaria que esses arquivos fossem classificados:
foo.txt foo2.txt foó3.txt foo4.txt
Em outras palavras, assim como com LC_COLLATE=en_US.utf8
, exceto que as pontuações são tratadas como caracteres significativos (que são classificados antes das letras).
Existe alguma configuração LC_COLLATE que faz isso?
Se não houver uma que respeite a pontuação e ofereça suporte a todos os recursos de 1 a 3, há pelo menos um que suporte o recurso 1 (ou seja, classifique como LC_COLLATE=c
, mas não garble caracteres Unicode)?