Início / unix / Perguntas / 777083
Accepted
Ben McIlwain
Asked: 2024-05-25 00:21:26 +0800 CST

O comando GNU sort não classifica palavras de comprimentos diferentes com prefixos comuns corretamente ao usar o delimitador de campo

  • 772

O comando GNU sort não está classificando palavras de comprimentos diferentes com prefixos comuns corretamente para mim, mas apenas ao usar um delimitador de campo para classificar um dos vários campos.

Aqui está o comportamento de classificação correto e esperado sem usar delimitadores de campo:

$ cat /tmp/test0
b
c
ant
a
bcd
bc
cn

$ sort /tmp/test0
a
ant
b
bc
bcd
c
cn

Observe que, para todas as palavras com um prefixo de string comum, a palavra mais curta é classificada antes da palavra mais longa. Por exemplo, aé antes ant, bé antes , bcé antes bcd, etc. Esta é a maneira padrão e aceita de classificação de strings em inglês, por exemplo, em um dicionário.

No entanto, esse comportamento de classificação muda quando você tenta classificar dados tabulares (como um arquivo CSV) e classificar em uma das colunas. Aqui está o que parece:

$ cat /tmp/test1
b,foo
c,bar
ant,baz
a,foo
bcd,ty
bc,pe
cn,cn

$ sort /tmp/test1 -t, -k1
a,foo
ant,baz
bcd,ty
bc,pe
b,foo
c,bar
cn,cn

Observe que as palavras com um prefixo comum ae cainda estão sendo tratadas corretamente, mas strings com um prefixo comum bnão; bcdclassifica antes bcclassifica antes b, tudo isso está incorreto! Este comportamento é estável; você sempre obtém o mesmo resultado. Estou enfrentando exatamente o mesmo problema em um arquivo CSV muito maior e os erros de classificação são deterministicamente aleatórios, se isso faz sentido.

Eu tentei vários sinalizadores sorte nenhum funcionou para corrigir esse comportamento. -de -snão funciona. Isso está no GNU coreutils 9.4, pelo que vale a pena.

Então, isso é apenas um bug do sortcomando? De alguma forma, estou usando-o incorretamente? Há algo melhor que eu possa fazer para classificar o CVS por palavras na primeira coluna?

command-line

3 respostas

  1. Best Answer

    É a maneira como sua localidade atual define regras de agrupamento/classificação que está causando isso e como -kNusa o campo Naté o final da linha ao comparar linhas, não apenas o campo N(e algumas localidades serão classificadas bc,peantes b,foose ignorarem as vírgulas).

    Use -k1,1para usar apenas esse campo específico ou especifique a localidade "C" e você deverá obter os resultados esperados:

    $ LC_ALL=en_US.utf8 sort -t, -k1 test.txt
a,foo
ant,baz
bcd,ty
bc,pe
b,foo
c,bar
cn,cn

$ LC_ALL=en_US.utf8 sort -t, -k1,1 test.txt
a,foo
ant,baz
b,foo
bc,pe
bcd,ty
c,bar
cn,cn

$ LC_ALL=C sort -t, -k1 test.txt
a,foo
ant,baz
b,foo
bc,pe
bcd,ty
c,bar
cn,cn
    • 8

  2. A resposta é que, apesar de alguns exemplos de uso online em contrário, o -ksinalizador leva DOIS parâmetros, portanto precisa ser escrito como -k 1,1. Caso contrário, com -k 1, ele não receberá um número de campo de parada e, portanto, apenas percorrerá a linha inteira. Portanto, o comportamento de classificação anômalo é na verdade causado pela representação UTF-8 do ,delimitador caindo em algum lugar entre os outros caracteres ASCII.

    Obrigado aos comentários de Stéphane Chazelas acima.

    • 3

  3. De acordo com o comentário de Stéphane Chazelas você está classificando toda a linha e não apenas o primeiro campo. Com LC_ALL=C ,classificações antes c:

    % LC_ALL=en_US.utf8 sort -t, -k1,1  test --debug 
sort: text ordering performed using ‘en_US.utf8’ sorting rules
a,foo
_
_____
ant,baz
___
_______
b,foo
_
_____
bc,pe
__
_____
bcd,ty
___
______
c,bar
_
_____
cn,cn
__
_____
% LC_ALL=en_US.utf8 sort -t, -k1  test --debug 
sort: text ordering performed using ‘en_US.utf8’ sorting rules
a,foo
_____
_____
ant,baz
_______
_______
bcd,ty
______
______
bc,pe
_____
_____
b,foo
_____
_____
c,bar
_____
_____
cn,cn
_____
_____
    • 2

relate perguntas