Por que o tipo diz que ɛ = e?

ɛ("Latin epsilon") é uma letra usada em certas línguas africanas, geralmente para representar o som da vogal no inglês "bed". No Unicode, é codificado como U + 025B, muito diferente do cotidiano e.

No entanto, se eu sorto seguinte:

eb
ed
ɛa
ɛc

parece que sortconsidera ɛe eequivalente:

ɛa
eb
ɛc
ed

Oque esta acontecendo aqui? E existe uma maneira de criar ɛe ediferenciar para sortpropósitos?

Não, não os considera equivalentes, apenas têm o mesmo peso principal. Para que, na primeira aproximação, eles tenham a mesma classificação.

Se você olhar para / usr / share / i18n / locales / iso14651_t1_common (usado como base para a maioria das localidades) em um sistema GNU (aqui com glibc 2.27), você verá:

<U0065> <e>;<BAS>;<MIN>;IGNORE # 259 e
<U025B> <e>;<PCL>;<MIN>;IGNORE # 287 ɛ
<U0045> <e>;<BAS>;<CAP>;IGNORE # 577 E

e, ɛE Etem o mesmo peso primário, ee Emesmo peso secundário, apenas o terceiro peso diferencia-os.

Ao comparar strings, sort(a strcoll()função libc padrão é usada para comparar strings) começa comparando os pesos primários de todos os caracteres e só vai para o segundo peso se os strings forem iguais aos pesos primários (e assim por diante com os outros pesos) .

É assim que o caso parece ser ignorado na ordem de classificação na primeira aproximação. Absortes entre aae ac, mas Abpode classificar antes ou depois ab, dependendo da regra de linguagem (algumas línguas têm <MIN>antes <CAP>como em Inglês Britânico, alguns <CAP>antes <MIN>como em estoniano).

Se etivesse a mesma ordem de classificação que ɛ, printf '%s\n' e ɛ | sort -uretornaria apenas uma linha. Mas como <BAS>antes <PCL>, esó antes ɛ . eɛeclassifica depois EEE(no peso secundário), mesmo que EEEclassifique depois eee(para o qual precisamos subir até o terceiro peso).

Agora, se no meu sistema com glibc 2.27, eu corro:

sed -n 's/\(.*;[^[:blank:]]*\).*/\1/p' /usr/share/i18n/locales/iso14651_t1_common |
  sort -k2 | uniq -Df1

Você notará que existem alguns caracteres que foram definidos com exatamente os mesmos 4 pesos. Em particular, nosso ɛ tem os mesmos pesos que:

<U01DD> <e>;<PCL>;<MIN>;IGNORE
<U0259> <e>;<PCL>;<MIN>;IGNORE
<U025B> <e>;<PCL>;<MIN>;IGNORE

E com certeza:

$ printf '%s\n' $'\u01DD' $'\u0259' $'\u025B' | sort -u
ǝ
$ expr ɛ = ǝ
1

Isso pode ser visto como um bug dos locais de GNU libc. Na maioria dos outros sistemas, as localidades garantem que todos os caracteres diferentes tenham ordem de classificação diferente no final. Em localidades GNU, fica ainda pior, pois há milhares de caracteres que não têm uma ordem de classificação e acabam classificando o mesmo, causando todo tipo de problemas (como quebrar comm, join, lsou globs tendo ordens não-deterministas ... ), daí a recomendação de usar LC_ALL=Cpara solucionar esses problemas .

Como observado por @ninjalj nos comentários, o glibc 2.28 lançado em agosto de 2018 veio com algumas melhorias nessa frente do AFAICS, ainda existem alguns caracteres ou elementos de classificação definidos com ordem de classificação idêntica. No Ubuntu 18.10 com glibc 2.28 e em um local en_GB.UTF-8.

$ expr $'L\ub7' = $'L\u387'
1

(por que U + 00B7 seria considerado equivalente a U + 0387 somente quando combinado com L/ l?!).

E:

$ perl -lC -e 'for($i=0; $i<0x110000; $i++) {$i = 0xe000 if $i == 0xd800; print chr($i)}' | sort > all-chars-sorted
$ uniq -d all-chars-sorted | wc -l
4
$ uniq -D all-chars-sorted | wc -l
1061355

(ainda mais de 1 milhão de caracteres (95% do intervalo Unicode, abaixo de 98% em 2.27) classificando da mesma forma que outros caracteres, pois sua ordem de classificação não está definida).

Veja também:

• O que faz "LC_ALL = C"?
• Gere a ordem de intercalação de uma sequência
• Qual é a diferença entre "sort -u" e "sort | uniq"?

homem classificar:

   ***  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.

Então tente: LC_ALL=C sort file.txt

O caractere ɛ não é igual a e, mas algumas localidades podem reunir esses sinais juntos após o agrupamento. A razão para isso é específica da linguagem, mas também alguns antecedentes históricos ou mesmo políticos. Por exemplo, a maioria das pessoas provavelmente espera que a moeda euro se aproxime da Europa no dicionário.

De qualquer forma, para ver qual agrupamento você está usando atualmente locale, locale -aele fornecerá a lista de códigos de idioma disponíveis no sistema e, para alterar o agrupamento, digamos Capenas para uma execução de classificação LC_COLLATE=C sort file. Finalmente, para ver como diferentes localidades podem classificar seu arquivo, tente

for loc in $(locale -a)
    do echo ____"${loc}"____
    LC_COLLATE="$loc" sort file
done

Canalize o resultado para alguma ferramenta de greping para escolher o local que atenda às suas necessidades.