RESPUESTA ACTUALIZADA:
PROBLEMA:
El OP está recibiendo un error sobre "el archivo no está en orden " cuando se usa comm
para comparar enteros positivos en los archivos, no texto. Entonces estamos tratando con números no decimales.
Respuesta corta:
Dependiendo del uso del -n
interruptor con el sort
comando utilizado para ordenar los resultados suministrados comm
, el orden de los resultados devueltos por comm
puede ser muy diferente:
Lexográfico : el uso del -n
interruptor con clasificación dará como resultado que se ordenen los "enteros positivos" en una serie de números crecientes. El " error " se puede suprimir utilizando comm
el interruptor `s--nocheck-order
Orden de bytes : NO hay uso de -n switch
con sort
. LC_COLLATE
determina el orden que incluso puede variar según la locale
configuración del host en el que se ejecuta el comando. Esta es la entrada que se comm
espera por defecto. LC_COLLATE
Puede encontrar un poco más sobre esto: Referencia1 y Referencia2
¿Es el error un problema?
Eso depende de lo que intentes lograr. Como verá en los ejemplos a continuación,comm
devuelve los mismos resultados después de comparar los archivos con o sin sort
el-n
interruptor`s, aunque su orden variará de la manera anterior dependiendo de si-n switch
se usa con elsort
comando. Yo prefiero los resultados ordenados "lexográficos", números que aumentan en una serie.
Sin embargo, si no desea los resultados en orden " lexográfico ", NO use el -n
interruptor al ordenar los datos suministrados comm
para la comparación.
PRUEBAS:
Compararemos los resultados del comm
comando con y sin el -n
interruptor. He aumentado la complejidad de mi conjunto de datos de prueba de muestras por solicitud de Kusalananda:
Datos de prueba :
file1.txt :
40
110000
2200
6
33000
file2.txt :
2200
40
33000
6
440000
intersección :
Lista solo los números comunes a AMBOS archivos
Sin -n
interruptor:
comm -12 <(sort file1.txt) <(sort file2.txt)
2200
33000
40
6
Resultados : correcto, pero devuelto en un orden no ordenado
Con -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 : Correcto, pero devuelto en un orden ordenado LEXOGRÁFICO . La operación se completó correctamente y devolvió los mismos resultados que si se usara comm
sin el -n
interruptor, pero en una lista ordenada.
Diferencia :
Lista solo números únicos para cada archivo:
Sin -n
interruptor:
comm -3 <(sort file1.txt) <(sort file2.txt)
110000
440000
Resultados : Correcto: estos números son exclusivos de cada archivo respectivo.
Con -n
interruptor:
comm -3 <(sort -n file1.txt) <(sort -n file2.txt)
110000
comm: file 1 is not in sorted order
440000
Resultados : Correctos, los mismos resultados que comm
sin el -n
modificador, pero devuelve el error sobre el orden de los enteros positivos que no se ordenan en los propios archivos.
SOLUCIÓN para RESULTADOS LEXOGRÁFICOS:
Use comm
el --nocheck-order
interruptor `s para suprimir el mensaje de error. Como sabemos que los números no están ordenados en cada archivo pero los resultados devueltos comm -n
son correctos, el error puede ignorarse de forma segura al suprimirlo:
intersección :
comm -12 --nocheck-order <(sort -n file1.txt) <(sort -n file2.txt)
6
40
2200
33000
Diferencia :
comm -3 --nocheck-order <(sort -n file1.txt) <(sort -n file2.txt)
110000
440000
CONCLUSIÓN:
El error "el archivo no está en orden de clasificación " cuando se devuelve la clasificación de enteros positivos alimentados comm
no significa que los resultados devueltos con el -n
interruptor con comm
estén incorrectos. De hecho, el uso comm -n
devuelve un orden correcto en un orden ordenado.
Gracias a @dhag, @kusalananda @ChrisDown por plantear los problemas que requerían una mayor expansión. Siempre feliz de que mi trabajo sea revisado: la única forma en que podemos mejorar es si nuestros pares nos presionan y desafían constantemente.