Le tri n'est pas cohérent à l'aide de la commande Unix "tri"

Je gère la commande:

zcat [File] | sed "1d" | sort -t $'\xE7' -k [field to be sorted] > [file].sorted 

Lorsque je l'exécute sur le fichier A, en triant sur le champ 1, j'obtiens le résultat suivant:

 11622400 , abe, def 11622401 , abe, def 11622402 , bbabe, def 11622403 , ddabe, def 11622404 , acdc, dere 11622405 , ddabe, bere 11622406 , abe, fgh 11622407 , adbed, ddee 11622408 , adbe, def 11622409 , abdde, def 1162240 , abe, deed 11622410, def,dede 

Mais lorsque je lance la même commande sur le tri du fichier 2 sur le champ 2, j'obtiens ceci:

 1162303, 116224 1162420, 1162240 11623062, 11622400 11623063, 11622401 11623064, 11622402 11623065, 11622403 11623066, 11622404 11623067, 11622405 11623068, 11622406 11623069, 11622407 11623070, 11622408 11623071, 11622409 1162421, 1162241 11623072, 1162410 

Pourquoi ne pas trier de la même manière? Le premier exemple semble erroné, la deuxième ligne du bas devrait être en haut.

J'essaie de rejoindre ces fichiers avec la commande Unix join , mais parce que ceux-ci ne commandent pas de la même manière, il manque beaucoup d'enregistrements.

Quelle est la raison de ce problème?

La raison pour laquelle vous obtenez ces résultats est que votre type n'est pas numérique, il est basé sur les valeurs canoniques des colonnes.

Il y a un commutateur de ligne de commande pour trier numériquement, c'est ce que vous voulez (tapez 'man sort' dans votre barre de google)

Il y a un problème avec votre question: vous prétendez utiliser $'\xE7' comme séparateur d'enregistrement, mais cet octet n'apparaît pas dans le fichier. Si c'est vraiment la commande que vous avez exécutée et ce sont vraiment vos sorties, le fichier A a été trié en fonction de la ligne entière et le fichier B a été trié de façon aléatoire (tous les champs 2 sont vides et le sort n'est pas stable par défaut). Cependant, comme le fichier 2 est trié sur le deuxième champ " , " séparé dans votre sortie du fichier B, je suppose que c'est un bug dans votre question et que votre code a utilisé un espace ou une virgule comme séparateur ou que vos données contiennent l'octet E7 où vos données ici ont une virgule et un espace.

Si vous passez une option -t pour définir un séparateur pour le tri, vous devez passer le même séparateur pour vous join . Dans tous les cas, vous devez indiquer si vous souhaitez join colonnes. Par exemple:

 <a.input sort -t $'\xE7' -k1 >a.sorted <b.input sort -t $'\xE7' -k2 >b.sorted join -1 1 -2 2 -t $'\xE7' a.sorted b.sorted >joined 

En outre, étant donné que " 11622409 , " s'affiche avant " 1162240 , ", dans votre sortie du fichier A, il apparaît que vous exécutez sort dans un environnement local qui produit des résultats approchant des règles de tri humain (uniquement approchant, car le sort n'est pas raffiné Assez pour correspondre aux règles assez compliquées utilisées dans la typographie grave). Vous obtiendrez des résultats moins surprenants si vous modifiez vos paramètres régionaux à celui qui produit des résultats adaptés à la consommation informatique. En pratique, cela signifie que votre paramètre LC_COLLATE devrait être C (ou son synonyme POSIX ). (Toute autre localisation tend à briser les scripts qui utilisent le sort , bien que le vôtre devrait en fait être correct.) Exemple:

 $ cat a 11622409 , abdde, def 1162241 , abe, deed 11622410, def,dede $ LC_COLLATE=en_US sort <a 11622409 , abdde, def 11622410, def,dede 1162241 , abe, deed $ LC_COLLATE=C sort <a 11622409 , abdde, def 1162241 , abe, deed 11622410, def,dede 

Si vous exécutez join dans le même lieu que sort , vous devriez être ok. Notez que ce sort produit une sortie triée lexicalement , non trié numériquement ; Mais c'est ce que vous voulez en tant que contribution à vous join .

Essayer:

 zcat [File] | sed "1d" | sort -tn $'\xE7' -k [field to be sorted] > [file].sorted