sort -rn produces output different from gnusort

[svetasmirnova]

I have a file with the following content:

$ cat /tmp/sveta 
      1 lock/lock0lock.c line 5163
      1 lock/lock0lock.c line 3249
      1 fsp/fsp0fsp.c line 3395
      1 btr/btr0cur.c line 672
      1 btr/btr0cur.c line 450
      1 ./include/btr0btr.ic line 53

If I run gnusort on my file, I get the following results (expected):

$ gnusort -r /tmp/sveta 
      1 lock/lock0lock.c line 5163
      1 lock/lock0lock.c line 3249
      1 ./include/btr0btr.ic line 53
      1 fsp/fsp0fsp.c line 3395
      1 btr/btr0cur.c line 672
      1 btr/btr0cur.c line 450

With sort -nr I get a different order (pay attention for the last line):

$ sort -nr /tmp/sveta 
      1 lock/lock0lock.c line 5163
      1 lock/lock0lock.c line 3249
      1 fsp/fsp0fsp.c line 3395
      1 btr/btr0cur.c line 672
      1 btr/btr0cur.c line 450
      1 ./include/btr0btr.ic line 53

However, if I use pipe sort -n | sort -r, the results are the same as with gnusort:

$ sort -n /tmp/sveta | sort -r
      1 lock/lock0lock.c line 5163
      1 lock/lock0lock.c line 3249
      1 ./include/btr0btr.ic line 53
      1 fsp/fsp0fsp.c line 3395
      1 btr/btr0cur.c line 672
      1 btr/btr0cur.c line 450

[sylvestre]

Which version do you try with? Thanks

[svetasmirnova]

$ sort --version
sort (uutils coreutils) 0.8.0

The one that comes with Ubuntu 26

[Franklin-Qi]

@sylvestre @svetasmirnova I believe this is normal. I'm also using Ubuntu 26.04, and here is my output.

$  sort --version
sort (uutils coreutils) 0.8.0

$ sort  -nr /tmp/sveta 
1 lock/lock0lock.c line 5163
1 lock/lock0lock.c line 3249
1 fsp/fsp0fsp.c line 3395
1 btr/btr0cur.c line 672
1 btr/btr0cur.c line 450
1 ./include/btr0btr.ic line 53

$ cargo run -q sort  -nr /tmp/sveta 
1 lock/lock0lock.c line 5163
1 lock/lock0lock.c line 3249
1 fsp/fsp0fsp.c line 3395
1 btr/btr0cur.c line 672
1 btr/btr0cur.c line 450
1 ./include/btr0btr.ic line 53

$ sort -r /tmp/sveta 
1 lock/lock0lock.c line 5163
1 lock/lock0lock.c line 3249
1 ./include/btr0btr.ic line 53
1 fsp/fsp0fsp.c line 3395
1 btr/btr0cur.c line 672
1 btr/btr0cur.c line 450

$ cargo run -q sort -r /tmp/sveta 
1 lock/lock0lock.c line 5163
1 lock/lock0lock.c line 3249
1 ./include/btr0btr.ic line 53
1 fsp/fsp0fsp.c line 3395
1 btr/btr0cur.c line 672
1 btr/btr0cur.c line 450

[svetasmirnova]

I cannot use sort -r here, because real file is larger and it contains numbers different than 1.

[lauchimoon]

Hello, I was looking into this issue and I believe that in the last resort compare, the function compare_by is using byte-by-byte comparison. I think that locale comparison should be used, for example:

(in sort.rs)
...
2795    // Call "last resort compare" if all selectors returned Equal
2796    let cmp = if global_settings.mode == SortMode::Random
2797        || global_settings.stable
2798        || global_settings.unique
2799    {
2800        Ordering::Equal
2801    } else {
2802        locale_cmp(a.line, b.line)
2803        // a.line.cmp(b.line)
2804    };
...

It's worth mentioning that when running gnusort and sort with LC_ALL=C the output was the same in both programs.

I made this change and it passed all tests from the test suite, alongside some new tests.

If it sounds good, I can send a pull request. Otherwise, I can wait for comments.

NOTE: I'm not sure if locale_cmp should be called at this point in the program.