Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

Sort is sorting differently than I would expect. I have this file, call it text.txt:

a   1
A   1
a   11

(the space is always one \t)

I want to sort them alphabetically by the first column. However, when I do

sort -k 1 text.txt

all I got is the text.txt file, not sorted. If I do it by the deprecated + - notation, meaning

sort +0 -1 text.txt

it works as it should, meaning that I get this output:

a   1
a   11
A   1

This strange behaviour occurs only when I have lines that differs only by case. What am I doing wrong?

share|improve this question
    
In the default locale, A would be before a. Most locales have a weird collation order; it's often best to keep LC_COLLATE=C. On this issue, see Does (should) LC_COLLATE affect character ranges? Why are capital letters included in a range of lower-case letters in an awk regex? –  Gilles Sep 1 '11 at 22:45
    
This issue, however, stands with LC_COLLATE=C (I think, I don't have a shell here now), the problem was really in the columns... however.... it probably should not be. I don't know. I will test it tomorrow. Thanks for the tips. –  Karel Bílek Sep 3 '11 at 2:57
add comment

2 Answers 2

up vote 5 down vote accepted

You have to specify the end column, too:

$ sort -k1,1 text.txt
a       1
a       11
A       1

To quote the GNU sort man page:

   -k, --key=POS1[,POS2]
          start a key at POS1 (origin 1), end it at POS2 (default  end  of
          line)
share|improve this answer
    
Oh. I guess I should have RTFM more carefully :) Thanks. –  Karel Bílek Aug 31 '11 at 20:38
1  
It is really strange that this was needed - the POS2 is evidently optional. Maybe a bug in sort? –  rozcietrzewiacz Sep 1 '11 at 8:15
1  
@rozcietrzewiacz, yes, it is optional. No, it is not a bug. POS2 is optional, but when you don't specify it then the default is used, i.e. the key then contains all columns up to the next newline. –  maxschlepzig Sep 1 '11 at 17:20
add comment

You most certainly hit upon a bug in sort! If you had no spaces in the file, there would be no way to sort it properly:

$ cat aaa
a1
A1
a11

$ sort aaa
a1
A1
a11

$ sort -k1,1 aaa
a1
A1
a11

Even more visible with the following:

$ cat bbb
A B b 0
a B b 0
A b b 1

$ sort bbb
a B b 0
A B b 0
A b b 1

$ sort -k1,2 bbb
a B b 0
A b b 1
A B b 0
share|improve this answer
    
That behaviour is correct, though. I think. –  Karel Bílek Sep 1 '11 at 20:35
    
Not a bug, but a collation locale issue: Karel clearly has a $LC_LOCALE that is not POSIX, since A isn't before a. On this issue, see Does (should) LC_COLLATE affect character ranges? Why are capital letters included in a range of lower-case letters in an awk regex? –  Gilles Sep 1 '11 at 22:43
    
@Gilles The problem isn't just that A is before or after a - it is that in some cases it is treated as before, in other as after. –  rozcietrzewiacz Sep 2 '11 at 6:17
1  
@Gilles Ok, so I understand now that the problem is with locale, not sort itself - but two letters being defined as equivalent? This is absurd! Who and why ever came up with this? –  rozcietrzewiacz Sep 2 '11 at 7:04
1  
@Gilles Case insensitive sorts would be nice as an option in some cases - but not as the default for locales like en_US.UTF-8! Furthermore, the case is even more complicated than this. The simple test suggested in this answer prints, depending on locale, either A > a or a < A but never A = a. Yet, the sort aliasing... –  rozcietrzewiacz Sep 2 '11 at 7:22
show 2 more comments

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.