Quero classificar os arquivos de acordo com o número no nome do arquivo. Aqui estão os arquivos:
$ ls *.f
0.f 13.f 1.f 22.f 4.f abc.f
O resultado da classificação:
$ ls *.f | sort -t. -k1n
0.f
abc.f # note this file!
1.f
4.f
13.f
22.f
O que eu esperava era:
$ ls *.f | sort -t. -k1n
abc.f
0.f
1.f
4.f
13.f
22.f
Por que foi abc.fmostrado logo após 0.fe antes 1.f? É porque 0não é tratado como um número por sort? Pesquisei na web e não encontrei nenhuma referência.
Respostas:
O motivo é que, ao usar a classificação numérica, as seqüências sem números são tratadas como zero. A classificação GNU corrige o comportamento, mas não faz nenhum comentário sobre o porquê. A página de manual em illumos para classificação do SunOS fornece uma explicação:
-n
Restringe a chave de classificação a uma sequência numérica inicial, consistindo em caracteres em branco opcionais, sinal de menos opcional e zero ou mais dígitos com um caractere de raiz opcional e separadores de milhares (conforme definido no código de idioma atual), que é classificado pelo valor aritmético . Uma sequência de dígitos vazia é tratada como zero. Zeros à esquerda e sinais em zeros não afetam a ordem.
Esse comportamento também é especificado no SUSv4 e no POSIX.1-2008 ( http://pubs.opengroup.org/onlinepubs/9699919799/utilities/sort.html ), usando a mesma verbosidade da página do manual illumos.
A classificação GNU também possui -g"classificação numérica geral", que é classificada por números de ponto flutuante, em vez de números inteiros, onde as cadeias de dígitos vazias são classificadas antes de zero. Não tenho certeza se esse é um efeito colateral ou intencional. No entanto, -gvem com um aviso, pois é significativamente mais lento que -n. Se você estiver classificando um grande conjunto de dados ou fazendo qualquer coisa que os usuários aguardem, evite -g.
sortlida com duas linhas com a mesma chave.
LC_ALL=C.