2010-04-22 9 views
6

kiedy próbuję uporządkować 'wejście' Następujący plik tekstowy:nieoczekiwany wynik z GNU sort

test1 3 
test3 2 
test 4 

z poleceniem

sort input 

wyjście jest dokładnie wejście. Oto wyjściowy

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 

To tylko zakładka oddzielone plik z dwoma kolumnami. Kiedy zrobić

sort -k 2 

Zmiany wyjściowe do

test3 2 
test1 3 
test 4 

który jest co by się spodziewać. Ale jeśli nie wykonam żadnych zmian w odniesieniu do danych wejściowych, natomiast oczekuję, że "test" zostanie posortowany przed "test1". Wreszcie, jeśli robię

cat input | cut -f 1 | sort 

uzyskać

test 
test1 
test3 

zgodnie z oczekiwaniami. Czy istnieje logiczne wytłumaczenie tego? Co domyślnie powinno się domyślnie robić: coś takiego:

sort -k 1 

?

Moja wersja rodzaju:

sort (GNU coreutils) 7.4 
+1

Nawet z algorytmu sortowania naturalnego, wejście (jak na rysunku) jest już posortowana. –

Odpowiedz

7

Od strony podręcznika:

* UWAGA * Ustawienia regionalne określone przez środowisko wpływa sortowania zamówienia. Ustaw LC_ALL = C, aby uzyskać tradycyjną kolejność sortowania, która używa natywnych wartości bajtowych .

Więc wydaje eksportowej LC_ALL = C musi pomóc

+0

Sortowanie GNU z LC_ALL = C daje tradycyjną odpowiedź - i tak to "sortuje" na Solaris. Zmień linię "test3" na "Test3", a otrzymasz więcej różnic. Odpowiedzi GNU są zgodne z porządkiem sortowania "ls". Jest to jednak zaskakujące. –

+0

Dzięki, dla mnie też daje oczekiwany rezultat. Jednak w moim domyślnym locale en_US.UTF-8 zarówno tabulacja, jak i spacja sortują również przed znakami alhpanumerycznymi. Jeśli sort jest po prostu leksykograficznym rodzajem na całej linii, to także mnie to zaskakuje. – user323338

+3

+1 To działa. Ale dlaczego??? –