J'ai deux fichiers _jeter3.txt et _jeter1.txt
J'ai vérifié qu'ils sont tous les deux triés sur la 20e colonne en utilisant sort -c
sort -t ' ' -c -k20,20 _jeter3.txt
sort -t ' ' -c -k20,20 _jeter1.txt
#no errors
mais il y a une erreur quand je veux les join
deux fichiers ça dit que le deuxième fichier n'est pas trié:
join -t ' ' -1 20 -2 20 _jeter1.txt _jeter3.txt > /dev/null
join: File 2 is not in sorted order
Je ne comprends pas pourquoi.
cat /etc/*-release #FYI
openSUSE 11.0 (i586)
VERSION = 11.0
MISE À JOUR : l'utilisation de ' sort -f
' et join -i
(les deux ne respectant pas la casse) corrige le problème. Mais cela n'explique pas mon problème initial.
UPDATE : versions de sort & join:
> join --version
join (GNU coreutils) 6.11
Copyright (C) 2008 Free Software Foundation, Inc.
(...)
> sort --version
sort (GNU coreutils) 6.11
Copyright (C) 2008 Free Software Foundation, Inc.
(...)
locale
.Réponses:
J'ai eu la même erreur avec Ubuntu 11.04, avec
sort
et lesjoin
deux dans la version (GNU coreutils) 8.5.Ils sont clairement incompatibles. En fait la
sort
commande semble buggée: il n'y a pas de différence avec ou sans l' option-f
(--ignore-case
). Lors du tri,aaB
c'est toujours avantaBa
. Les caractères non alphanumériques semblent également toujours ignorés (abc
avantab-x
)Join semble s'attendre à l'inverse ... Mais j'ai une solution
En fait, cela est lié à la séquence de classement: utiliser
LANG=en_EN sort -k 1,1 <myfile> ...
puisLANG=en_EN join ...
élimine le message.L'internationalisation est la racine du mal ... (personne ne le documente clairement).
la source
LANG=en_EN
, cela fonctionnera certainement? Cela fonctionnera-t-il pour n'importe quel environnement local, tant que les deux utilisent le même environnement local? Pouvons-nous dire que la différence entresort
etjoin
est qu'ils utilisent une locale différente par défaut?-k
option est-elle la réponse ici, ou est-ce laLANG=en_EN
? On ne sait pas quelle est la solution exacte ici.Étiez-vous en train de trier avec des nombres? J'ai trouvé que le remplissage nul de la colonne que je rejoignais a résolu ce problème pour moi.
la source
Si vous êtes sûr d'avoir correctement trié vos fichiers d'entrée et que leurs lignes peuvent être associées, vous pouvez éviter l'erreur ci-dessus en exécutant
join --nocheck-order file1.txt file2.txt
la source
sort
utilise par défaut la ligne entière comme cléjoin
utilise uniquement le champ spécifié comme clé.Vous devez corriger cette incompatibilité en limitant le tri à utiliser uniquement la clé sur laquelle vous souhaitez vous connecter.
La page de manuel Join indique:
la source
Cela résoudra votre problème. Le problème, comme l'a souligné @Michael, est la séquence de classement, qui dépend de votre paramètre LOCALE.
la source
Notez que si vous voyez cette erreur et que vous avez déjà trié sur une colonne spécifique et que vous vous battez la tête contre le mur, par exemple sort -k4,4, vous devrez peut-être également définir le séparateur pour la commande de tri
Apparemment, OP l'a déjà fait avec -t '' mais pour un texte normal séparé par des tabulations, je recommanderais
La commande sort peut incorporer des espaces comme séparateurs par défaut même sur quelque chose qui ressemble à un fichier séparé par des tabulations (surtout s'il y a des espaces à l'intérieur de la colonne sur laquelle vous effectuez le tri).
Ensuite, si vous avez transmis ces données triées à joindre, et que vous avez
Ensuite, cela finit par provoquer le message d'erreur à ce sujet non trié. Comme indiqué ci-dessus, join peut ne pas accepter -t '' cependant.
la source
Pour join l'argument après -t est un caractère. Pour le tri, vous pouvez fournir un séparateur de tri plus long. Je pense que vous pouvez joindre les fichiers sur un champ différent que vous souhaitez, et ignorer le cas résout le problème par coïncidence.
Et je suis d'accord avec Gilles, que des exemples de données seraient utiles.
la source