Bug 253817 - The -v option of ls does not handle /boot version numbers properly
The -v option of ls does not handle /boot version numbers properly
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: coreutils (Show other bugs)
5.0
All Linux
low Severity low
: ---
: ---
Assigned To: Ondrej Vasik
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-08-22 00:57 EDT by arch harris
Modified: 2009-09-02 05:17 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-09-02 05:17:29 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
patch for rawhide coretuils (1.36 KB, patch)
2008-09-04 04:53 EDT, Kamil Dudka
no flags Details | Diff

  None (edit)
Description arch harris 2007-08-22 00:57:38 EDT
Description of problem:

The -v option of ls should sort files by version umber but it does not work
properly when handling version numbers like those used in /boot/vmlinuz* files.
For example, of vmlinuz-2.6.18-8.1.8.el5 and vmlinuz-2.6.18-8.el5, `ls -v'
imporpoerly lists vmlinuz-2.6.18-8.el5 as the more recent.


Version-Release number of selected component (if applicable):


How reproducible:
Always


Steps to Reproduce:
1. ls -v /boot/vm
2.
3.
  
Actual results:
vmlinuz-2.6.9-5.0.3.EL
vmlinuz-2.6.9-5.0.5.EL
vmlinuz-2.6.9-5.EL
vmlinuz-2.6.9-11.EL
vmlinuz-2.6.9-22.0.1.EL
vmlinuz-2.6.9-22.0.2.EL
vmlinuz-2.6.9-22.EL
vmlinuz-2.6.9-34.0.1.EL
vmlinuz-2.6.9-34.EL
vmlinuz-2.6.9-42.0.2.EL
vmlinuz-2.6.9-42.0.3.EL
vmlinuz-2.6.9-42.0.8.EL
vmlinuz-2.6.9-42.0.10.EL
vmlinuz-2.6.9-55.0.2.EL
vmlinuz-2.6.9-55.EL



Expected results:
vmlinuz-2.6.9-5.EL
vmlinuz-2.6.9-5.0.3.EL
vmlinuz-2.6.9-5.0.5.EL
vmlinuz-2.6.9-11.EL
vmlinuz-2.6.9-22.EL
vmlinuz-2.6.9-22.0.1.EL
vmlinuz-2.6.9-22.0.2.EL
vmlinuz-2.6.9-34.EL
vmlinuz-2.6.9-34.0.1.EL
vmlinuz-2.6.9-42.0.2.EL
vmlinuz-2.6.9-42.0.3.EL
vmlinuz-2.6.9-42.0.8.EL
vmlinuz-2.6.9-42.0.10.EL
vmlinuz-2.6.9-55.EL
vmlinuz-2.6.9-55.0.2.EL




Additional info:
Comment 1 Ondrej Vasik 2007-12-03 06:39:02 EST
Thanks for report. ls is using strverscmp function for -v option. There was
already one similar bug filled against that function in glibc (
http://sourceware.org/bugzilla/show_bug.cgi?id=3506 ) and was closed that this
is required behaviour. Coreutils have in lib subdir its own strverscmp.c file,
so maybe that could be changed for coreutils to correct version displaying. But
now is the glibc function used (at least in coreutils I have checked) - and this
one will not change. Will try to find something more about the possible solution
- because current behaviour is wrong for RHEL/Fedora versioned files with dist tag.
Comment 2 Kamil Dudka 2008-09-04 04:53:48 EDT
Created attachment 315725 [details]
patch for rawhide coretuils

Possible solutions of this issue were proposed upstream by Ondrej Vasik, you can watch the thread at http://lists.gnu.org/archive/html/bug-gnulib/2008-09/msg00027.html

I am not sure if change of known ls behavior is acceptable by coreutils upstream. But there is new option --version-sort (-V) in sort utility, which has not been released yet. So if it will be accepted at least for sort, you can use then 'ls | sort -V' instead.

Anyway I am attaching a patch for rawhide coreutils, which gives expected results.
Comment 3 Kamil Dudka 2008-10-06 09:56:59 EDT
New version compare algorithm will be presented in upcoming coreutils v7.0 - function filevercmp: http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=e505736f8211a608b00dfe75fb186a5211e1a183

The filevercmp function is designed as strverscmp replacement and is used in ls -v and sort -V as sort predicate.
Comment 5 Kamil Dudka 2009-03-05 17:10:27 EST
Slightly improved filevercmp behavior while comparing hidden files:
http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=0443c2f39943017f0aaa0afacbf68fb725858963
Comment 10 errata-xmlrpc 2009-09-02 05:17:29 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2009-1262.html

Note You need to log in before you can comment on or make changes to this bug.