4

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?

2

2 Answers 2

4

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)
3
  • Oh. I guess I should have RTFM more carefully :) Thanks. Aug 31, 2011 at 20:38
  • 1
    It is really strange that this was needed - the POS2 is evidently optional. Maybe a bug in sort? Sep 1, 2011 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. Sep 1, 2011 at 17:20
2

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
7
  • That behaviour is correct, though. I think. Sep 1, 2011 at 20:35
  • 1
    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? Sep 1, 2011 at 22:43
  • 1
    @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. Sep 2, 2011 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? Sep 2, 2011 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... Sep 2, 2011 at 7:22

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .