Version sort order is completely broken in MC 4.8.28

[birdie]

See the attached screenshot

[andrew_b]

Replying to birdie:

See the attached screenshot

What I should see there?

[birdie]

.mozilla.ram
.wine
.ICE-unix
.X11-unix
.font-unix
.wine-1000

I don't understand this sort order: .m*, .w*, .I*, .X*, .f*, .w*? What? Why?

[andrew_b]

Yes, this is a bug.

Branch: 4374_version_sort_fix
changeset:db109be8a28f1556495979ee7d1967e982cca6fd

[andrew_b]

Merged to master: [34d3726b79d35481e96f5fabe8e34e3439e6d9d9].

[birdie]

The maintainer in Fedora has applied the patch but it doesn't seem to work:

.mozilla.ram
.wine
.ICE-unix
.X11-unix
.XIM-unix
.chrome-cache
.font-unix
.vbox-birdie-ipc
.wine-1000

I don't understand this sort order.

[andrew_b]

Congratulations! You found a bug (but probably this is a feature) in gnulib.

I installed coreutils-9.1 (that contains a gnulib commit 9f48fb992a3d7e96610c4ce8be969cff2d61a01b) and I have the same result as above for ls -a1v and ls -a1 | sort -V:

.
..
.mozilla.ram
.wine
.ICE-unix
.X11-unix
.XIM-unix
.chrome-cache
.font-unix
.vbox-birdie-ipc
.wine-1000

[birdie]

Replying to andrew_b:

Congratulations! You found a bug (but probably this is a feature) in gnulib.

What's GNUlib? I don't have it installed on my Fedora 36 ;-)

Are you talking about glibc?

[birdie]

On Fedora 36:

sort -V 123.txt 
.ICE-unix
.X11-unix
.XIM-unix
.chrome-cache
.font-unix
.mozilla.ram
.vbox-birdie-ipc
.wine
.wine-1000

Looks correct.

$ ls --group-directories-first --sort=version -a . | cat
.
..
.ICE-unix
.X11-unix
.XIM-unix
.chrome-cache
.font-unix
.mozilla.ram
.vbox-birdie-ipc
.wine
.wine-1000

Again, it's correct.

[birdie]

$ ls --group-directories-first -a . | sort -V
.
..
.ICE-unix
.X0-lock
.X11-unix
.XIM-unix
.chrome-cache
.font-unix
.mozilla.ram
.vbox-birdie-ipc
.wine
.wine-1000

Also correct.

[birdie]

$ locale
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=

[andrew_b]

Replying to birdie:

Are you talking about glibc?

No, I'm talking about ​gnulib, a base library for many GNU tools, including coreutils.

On Fedora 36

This says me nothing. I'm not Fedora user. Show the output of ls --version or rpm -q coreutuls.

[birdie]

ls --version
ls (GNU coreutils) 9.0

rpm -q coreutils
coreutils-9.0-5.fc36.x86_64

[andrew_b]

Change ​9f48fb992a3d7e96610c4ce8be969cff2d61a01b was committed to gnulib 2022-02-12. Coreutils-9.1 was ​released 2022-04-15 and contains this change.

The version sort of ls-9.1 will differ than one of ls-9.0. Now this will not come as a surprise to you.
But you can try convince the gnulib developers that this is a bug: bug-gnulib@….

[birdie]

I've emailed the gnulib bug mailing list, they've confirmed the regression and the patch has already been released.

It's quite disturbing how ostensibly millions of people use Linux, yet I uncover such major bugs.

[andrew_b]

Branch: 4374_version_sort_fix2
changeset:dc67246c27c5697e67635e0019e7880a250e0c5e

[birdie]

Andrew, thanks a ton!

Is the patch from comment #3 still required?

[andrew_b]

Replying to birdie:

Andrew, thanks a ton!

Is the patch from comment #3 still required?

Yes.

I'll merge this branch to master today.

[andrew_b]

Merged to master: [0e583d756ed1fb1d42174d7be3d2d91b1e5df604].