Ticket #4374 (closed defect: fixed)

Opened 6 weeks ago

Last modified 4 weeks ago

Version sort order is completely broken in MC 4.8.28

Reported by: birdie Owned by: andrew_b
Priority: major Milestone: 4.8.29
Component: mc-core Version: 4.8.28
Keywords: Cc:
Blocked By: Blocking:
Branch state: merged Votes for changeset: committed-master

Description

See the attached screenshot

Attachments

version.png (15.8 KB) - added by birdie 6 weeks ago.

Change History

Changed 6 weeks ago by birdie

comment:1 in reply to: ↑ description Changed 6 weeks ago by andrew_b

Replying to birdie:

See the attached screenshot

What should I see there?

Last edited 6 weeks ago by andrew_b (previous) (diff)

comment:2 Changed 6 weeks ago by 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?

comment:3 Changed 6 weeks ago by andrew_b

  • Status changed from new to accepted
  • Owner set to andrew_b
  • Branch state changed from no branch to on rework

Yes, this is a bug.

Branch: 4374_version_sort_fix
changeset:db109be8a28f1556495979ee7d1967e982cca6fd

comment:4 Changed 5 weeks ago by andrew_b

  • Votes for changeset set to andrew_b
  • Branch state changed from on rework to approved

comment:5 Changed 5 weeks ago by andrew_b

  • Status changed from accepted to testing
  • Votes for changeset changed from andrew_b to committed-master
  • Resolution set to fixed
  • Branch state changed from approved to merged

comment:6 Changed 5 weeks ago by andrew_b

  • Status changed from testing to closed

comment:7 Changed 4 weeks ago by birdie

  • Status changed from closed to reopened
  • Resolution fixed deleted

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.

comment:8 follow-up: ↓ 9 Changed 4 weeks ago by 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
Last edited 4 weeks ago by andrew_b (previous) (diff)

comment:9 in reply to: ↑ 8 ; follow-up: ↓ 13 Changed 4 weeks ago by 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?

comment:10 Changed 4 weeks ago by 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.

comment:11 Changed 4 weeks ago by 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.

comment:12 Changed 4 weeks ago by 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=

comment:13 in reply to: ↑ 9 Changed 4 weeks ago by 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.

comment:14 Changed 4 weeks ago by birdie

ls --version
ls (GNU coreutils) 9.0

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

comment:15 Changed 4 weeks ago by 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@….

comment:16 Changed 4 weeks ago by 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.

comment:17 Changed 4 weeks ago by birdie

  • Summary changed from Version sort order is completely broken in MC 4.8.28 to Version sort order is completely broken in MC 4.8.28 [not our bug]

comment:18 Changed 4 weeks ago by andrew_b

  • Votes for changeset committed-master deleted
  • Branch state changed from merged to on review
  • Summary changed from Version sort order is completely broken in MC 4.8.28 [not our bug] to Version sort order is completely broken in MC 4.8.28

comment:19 follow-up: ↓ 20 Changed 4 weeks ago by birdie

Andrew, thanks a ton!

Is the patch from comment #3 still required?

comment:20 in reply to: ↑ 19 Changed 4 weeks ago by 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.

comment:21 Changed 4 weeks ago by andrew_b

  • Votes for changeset set to andrew_b
  • Branch state changed from on review to approved

comment:22 Changed 4 weeks ago by andrew_b

  • Status changed from reopened to closed
  • Votes for changeset changed from andrew_b to committed-master
  • Resolution set to fixed
  • Branch state changed from approved to merged
Note: See TracTickets for help on using tickets.