RÉPONSE MISE À JOUR:
PROBLÈME:
L'OP reçoit une erreur sur "le fichier n'est pas dans l'ordre de tri " lors de l'utilisation commpour comparer des entiers positifs dans les fichiers, pas du texte. Nous avons donc affaire à des nombres non décimaux.
Réponse courte:
En fonction de l'utilisation du -ncommutateur avec la sortcommande utilisée pour trier les résultats fournis comm, l'ordre des résultats renvoyés par commpeut être très différent:
Lexographique : L'utilisation du -ncommutateur avec tri entraînera le classement des "nombres entiers positifs" en une série de nombres croissants. L '" erreur " peut être supprimée à l'aide du commcommutateur `s--nocheck-order
Ordre des octets : Il n'y a AUCUNE utilisation du -n switchavec sort. LC_COLLATEdétermine l'ordre qui peut même varier selon la façon dont le localeest défini sur l'hôte où la commande est exécutée. Il s'agit de l'entrée commattendue par défaut. Un peu plus LC_COLLATEpeut être trouvé ici: Reference1 et Reference2
L'erreur est-elle un problème?
Cela dépend de ce que vous essayez de réaliser. Comme vousverrez dans les exemples cidessous,commrenvoie les mêmes résultats après avoir comparé les fichiers avec ou sans sort `-ncommutateur, bienleur commande varie de la manière cidessus selon que l'-n switchon utilise avec lasortcommande. Moi-même, je préfère les résultats ordonnés "lexographiques" - des nombres qui augmentent en série.
Cependant, si vous ne souhaitez pas que les résultats soient classés par ordre " lexographique ", n'utilisez PAS le -ncommutateur lors du tri des données fournies à des commfins de comparaison.
ESSAI:
Nous comparerons les résultats de la commcommande avec et sans le -ncommutateur. J'ai augmenté la complexité de mon ensemble de données de test d'échantillons à la demande de Kusalananda:
Données de test :
file1.txt :
40
110000
2200
6
33000
file2.txt :
2200
40
33000
6
440000
Intersection :
Répertorier uniquement les numéros communs aux DEUX fichiers
Sans -ninterrupteur:
comm -12 <(sort file1.txt) <(sort file2.txt)
2200
33000
40
6
Résultats : corrects, mais retournés dans un ordre non trié
AVEC -n interrupteur:
comm -12 <(sort -n file1.txt) <(sort -n file2.txt)
6
40
2200
33000
comm: file 1 is not in sorted order
Résultats : corrects, mais retournés dans un ordre trié LEXOGRAPHIQUE . L'opération s'est terminée avec succès et a renvoyé les mêmes résultats que l'utilisation commsans le -ncommutateur, mais dans une liste triée.
Différence :
Énumérez uniquement les numéros uniques à chaque fichier:
Sans -ninterrupteur:
comm -3 <(sort file1.txt) <(sort file2.txt)
110000
440000
Résultats : correct - ces chiffres sont en effet exclusifs à chaque fichier respectif.
AVEC -n interrupteur:
comm -3 <(sort -n file1.txt) <(sort -n file2.txt)
110000
comm: file 1 is not in sorted order
440000
Résultats : corrects, mêmes résultats que commsans le -ncommutateur, mais renvoie l'erreur sur l'ordre des entiers positifs non triés dans les fichiers eux-mêmes.
SOLUTION pour des RÉSULTATS LEXOGRAPHIQUES:
Utilisez le commutateur comm`s --nocheck-orderpour supprimer le message d'erreur. Comme nous savons que les nombres ne sont pas triés dans chaque fichier mais que les résultats renvoyés par comm -nsont corrects, l'erreur peut être ignorée en toute sécurité en le supprimant:
Intersection :
comm -12 --nocheck-order <(sort -n file1.txt) <(sort -n file2.txt)
6
40
2200
33000
Différence :
comm -3 --nocheck-order <(sort -n file1.txt) <(sort -n file2.txt)
110000
440000
CONCLUSION:
L'erreur «le fichier n'est pas dans l'ordre de tri » lorsque renvoyé le tri des entiers positifs alimentés commne signifie pas que les résultats renvoyés à l'aide du -ncommutateur avec commsont incorrects. En effet, l'utilisation comm -nrenvoie un bon ordre dans un ordre trié!
Merci à @dhag, @kusalananda @ChrisDown pour avoir soulevé les problèmes qui nécessitaient une expansion supplémentaire. Toujours heureux de voir mon travail révisé: la seule façon de s'améliorer, c'est d'être constamment poussés et mis au défi par nos pairs.