bug#41563: Possible bug with 'sort -Vr' version sorting

[Erik Auerswald]

Hi,

On Wed, May 27, 2020 at 02:07:32PM +0200, Danie de Jager via GNU coreutils Bug 
Reports wrote:
> I use sort -Vr to sort version numbers. I noticed this discrepancy on
> the latest kernel version from Centos 7.8.
> 
> command to get output:
> # ls -t /boot/vmlinuz-* | sed "s/\/boot\/vmlinuz-//g" | grep -v rescue
> | sort -Vr
> 3.10.0-1127.el7.x86_64
> 3.10.0-1127.8.2.el7.x86_64
> 3.10.0-1062.18.1.el7.x86_64
> 
> I'd expect the middle value to be the highest version number. Is this
> by design or a bug? If it is a bug please let me know if I must log it
> somewhere.

I'd say this is by design:

Sorting compares runs of non-digits, then runs of digits.  Thus each
"dot" (.) terminates a run of digits.  The "problem" is an unbalanced
number of digit and non-digit runs in the version numbers.

See the following two manual sections:
http://www.gnu.org/software/coreutils/manual/coreutils.html#Version_002dsort-ordering-rules
http://www.gnu.org/software/coreutils/manual/coreutils.html#Punctuation-Characters

The "version sort" is based on Debian's version sort (but different).
It seems as if Red Hat version numbers follow different rules.

HTH,
Erik
-- 
Be water, my friend.
-- Bruce Lee

bug#41563: Possible bug with 'sort -Vr' version sorting

[Danie de Jager via GNU coreutils Bug Reports]

Hi,

I use sort -Vr to sort version numbers. I noticed this discrepancy on
the latest kernel version from Centos 7.8.

command to get output:
# ls -t /boot/vmlinuz-* | sed "s/\/boot\/vmlinuz-//g" | grep -v rescue
| sort -Vr
3.10.0-1127.el7.x86_64
3.10.0-1127.8.2.el7.x86_64
3.10.0-1062.18.1.el7.x86_64

I'd expect the middle value to be the highest version number. Is this
by design or a bug? If it is a bug please let me know if I must log it
somewhere.

Version details:
# sort --version
sort (GNU coreutils) 8.22
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later .
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Mike Haertel and Paul Eggert.

Regards,
Danie de Jager

bug#41554: chmod allows removing x bit on chmod without a force flag, which can be inconvenient to recover from

[Andreas Schwab]

On Mai 26 2020, Will Rosecrans wrote:

> "chmod a-x $(which chmod)" not a particularly likely thing for a user to
> try to do directly, but it is conceivable for some sort of script to
> attempt it by accident because of a bug, and it would make the system
> inconvenient to recover.

It will likely fail with EPERM.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."