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ílekSep 3 '11 at 2:57

Oh. I guess I should have RTFM more carefully :) Thanks.
–
Karel BílekAug 31 '11 at 20:38

1

It is really strange that this was needed - the POS2 is evidently optional. Maybe a bug in sort?
–
rozcietrzewiaczSep 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.
–
maxschlepzigSep 1 '11 at 17:20

@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.
–
rozcietrzewiaczSep 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?
–
rozcietrzewiaczSep 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...
–
rozcietrzewiaczSep 2 '11 at 7:22