2010-04-22 10 views
6

lorsque je tente de trier « entrée » le fichier texte suivant:résultat inattendu de sorte gnu

test1 3 
test3 2 
test 4 

avec la commande

sort input 

la sortie est exactement l'entrée. Voici la sortie de

od -bc input 

:

0000000 164 145 163 164 061 011 063 012 164 145 163 164 063 011 062 012 
      t e s t 1 \t 3 \n t e s t 3 \t 2 \n 
0000020 164 145 163 164 011 064 012 
      t e s t \t 4 \n 
0000027 

Il est juste un onglet fichier séparé avec deux colonnes. Quand je fais

sort -k 2 

Les changements de sortie à

test3 2 
test1 3 
test 4 

qui est ce que je pense. Mais si je

sort -k 1 

rien ne change par rapport à l'entrée, alors que je me attends à ce « test » pour trier avant « test1 ». Enfin, si je

cat input | cut -f 1 | sort 

Je reçois

test 
test1 
test3 

comme prévu. Y a-t-il une explication logique à cela? Qu'est-ce qui est censé être fait par défaut, quelque chose comme:

sort -k 1 

?

Ma version de tri:

sort (GNU coreutils) 7.4 
+1

Même avec un algorithme de tri naturel, l'entrée (comme indiqué) est déjà trié. –

Répondre

7

A partir des pages de manuel:

* AVERTISSEMENT * Le paramètre régional spécifié par l'environnement affecte ordre de tri . Définissez LC_ALL = C pour obtenir l'ordre de tri traditionnel qui utilise les valeurs natives octets.

Il semble donc export LC_ALL = C doit aider

+0

Le tri GNU avec LC_ALL = C produit la réponse traditionnelle - ce que Solaris produit de toute façon. Changez la ligne 'test3' en 'Test3' et vous obtenez plus de différences. Les réponses GNU sont cohérentes avec l'ordre de tri de "ls". C'est surprenant, cependant. –

+0

Merci, pour moi aussi, cela produit le résultat attendu. Cependant, dans mon environnement local par défaut en_US.UTF-8, l'onglet et l'espace sont également triés avant les caractères alhpanumeric. Si le tri fait juste un tri lexicographique sur toute la ligne, cela reste un peu surprenant pour moi aussi. – user323338

+3

+1 Cela fonctionne. Mais pourquoi??? –

Questions connexes