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:
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.
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.
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.
Slightly improved filevercmp behavior while comparing hidden files: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=0443c2f39943017f0aaa0afacbf68fb725858963
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