Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I got a file named test, its content is like

111 222
11 22
111 223
12 22 33
11 2 25
222 331
11 2
33 2 1
33
33 22 33

I used:

sort -bk2.3 test

But the result confused me, those lines which doesn't have k2.3 are in a rather random sort. I'm expecting the target lines all listed at the beginning or the end, but it's not. It's like:

11 2
11 22
33
222 331
33 2 1
111 222
11 2 25
111 223
12 22 33
33 22 33

So, what's the inner mechanism of sort to rank those lines without a claimed key area?

share|improve this question
    
explain please more detailed which sort you would like to have. –  Ruslan Gerasimov Jun 16 at 13:08
    
Interesting. It is not random and not dependent on the original line order, as sort test | sort -bk2.3 gives the same output order, but I can't see any pattern. I also find sort test unexpected, with the 111 lines preceding the 11 lines, as though blank is later in the collating sequence than alphanumerics (I repeated with A instead of 1, etc, in the test file). All very puzzling. –  AFH Jun 16 at 16:43
    
@RuslanGerasimov, the practical file is much more hard to read, and I simplified it here –  Zen Jun 17 at 4:38
    
I mean could you please explain your intention, how you would like to sort - by what criteria? –  Ruslan Gerasimov Jun 17 at 4:46
    
@Ruslan Gerasimov, I expected 'sort' command can range the target lines together, whether at the beginning or tail of the output, instead of let them spread everywhere. –  Zen Jun 17 at 4:49

1 Answer 1

I highly recommend this Stack Overflow thread on the same topic. This behavior of sort is not intuitive, and despite studying both that thread and the official GNU Sort documentation I can't determine exactly what happens when a sort index is out of bounds.

  1. However, I must point out that you can use the "b" modifier as a sort key opt which ignores whitespace in that key, i.e. blank keys eg

    $ sort -k 2.3nb test

  2. Also from the GNU Sort documentation, it's clear the -k option takes an argument of the format start pos,end pos and if no end pos is specified it compares keys from your starting position until the end of the current line. This, together with the following caution are what's resulting in the undefined behavior.

    Finally, as a last resort when all keys compare equal, 
    sort compares entire lines as if no ordering options other 
    than --reverse (-r) were specified. 
    
  3. You can also specify multiple keys to act as a tie-breaker, though this doesn't solve for your use case because it's the first key that's causing the unintuitive behavior.

  4. Finally, if you have the --debug option available on your system as per the GNU Sort that would be much help troubleshooting because it reveals what is being matched with the key pattern. Unfortunately I didn't and so had to experiment in the dark.

I don't know what your use case is exactly, but I found a rather pleasing result set with the following. This behavior is likely not documented but observably seems to work as per my intuition and your request:

$ sort -k 2.3nb,2 test
11 2
11 2 25
11 22
12 22 33
33
33 2 1
33 22 33
222 331
111 222
111 223
share|improve this answer

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.