RESPOSTA ATUALIZADA:
PROBLEMA:
O OP está recebendo um erro sobre "o arquivo não está na ordem classificada " ao ser usado commpara comparar números inteiros positivos nos arquivos, não no texto. Então, estamos lidando com números não decimais.
Resposta curta:
Dependendo do uso do -ncomutador com o sortcomando usado para classificar os resultados fornecidos comm, a ordem dos resultados retornados por commpode ser muito diferente:
Lexográfico : O uso do -ncomutador com classificação resultará na ordenação de "Inteiros positivos" em uma série de números crescentes. O " erro " pode ser suprimido usando commo interruptor `s--nocheck-order
Ordem de bytes : NÃO há uso do -n switchcom sort. LC_COLLATEdetermina a ordem que pode até variar de acordo com a localeconfiguração no host em que o comando é executado. Essa é a entrada commesperada por padrão. Um pouco mais sobre isso LC_COLLATEpode ser encontrado aqui: Referência1 e Referência2
O erro é um problema?
Isso depende do que você está tentando alcançar. Como você verá nos exemplos abaixo,commretorna os mesmos resultados depois de comparar os arquivos com ou sem sort a-nopção`s, embora sua ordem varie da maneira acima, dependendo se-n switché usada com osortcomando. Eu mesmo prefiro resultados ordenados "lexográficos" - números que aumentam em uma série.
No entanto, se você não deseja os resultados na ordem " lexográfica ", NÃO use a -nopção ao classificar os dados fornecidos commpara comparação.
TESTE:
Compararemos os resultados do commcomando com e sem o -ncomutador. Aumentei a complexidade do meu conjunto de dados de teste de amostra por solicitação de Kusalananda:
Dados de teste :
file1.txt :
40
110000
2200
6
33000
file2.txt :
2200
40
33000
6
440000
Interseção :
Listar apenas números comuns a ambos os arquivos
Sem -ninterruptor:
comm -12 <(sort file1.txt) <(sort file2.txt)
2200
33000
40
6
Resultados : correto, mas retornado em um pedido não classificado
Com -n interruptor:
comm -12 <(sort -n file1.txt) <(sort -n file2.txt)
6
40
2200
33000
comm: file 1 is not in sorted order
Resultados : correto, mas retornado em uma ordem classificada LEXOGRAPHIC . A operação foi concluída com êxito e retornou os mesmos resultados que o uso commsem a -nopção, mas em uma lista classificada.
Diferença :
Liste apenas números exclusivos para cada arquivo:
Sem -ninterruptor:
comm -3 <(sort file1.txt) <(sort file2.txt)
110000
440000
Resultados : Correto - esses números são realmente exclusivos para cada arquivo respectivo.
Com -n interruptor:
comm -3 <(sort -n file1.txt) <(sort -n file2.txt)
110000
comm: file 1 is not in sorted order
440000
Resultados : Corretos, mesmos resultados que commsem a -nopção, mas retornam o erro sobre a ordem dos números inteiros positivos que não foram classificados nos próprios arquivos.
SOLUÇÃO PARA RESULTADOS LEXOGRÁFICOS:
Use comma --nocheck-orderopção `s para suprimir a mensagem de erro. Como sabemos que os números não são classificados em cada arquivo, mas os resultados retornados comm -nestão corretos, o erro pode ser ignorado com segurança, suprimindo-o:
Interseção :
comm -12 --nocheck-order <(sort -n file1.txt) <(sort -n file2.txt)
6
40
2200
33000
Diferença :
comm -3 --nocheck-order <(sort -n file1.txt) <(sort -n file2.txt)
110000
440000
CONCLUSÃO:
O erro "o arquivo não está na ordem de classificação " quando a classificação retornada de números inteiros positivos alimentados commnão significa que os resultados retornados usando a -nopção com commestão incorretos. De fato, usar comm -nretorna um arrumado correto em uma ordem classificada!
Graças a @dhag, @kusalananda @ChrisDown por levantar as questões que exigiam maior expansão. Sempre feliz em revisar meu trabalho: a única maneira de melhorar é se somos constantemente pressionados e desafiados por nossos colegas.