Re: Issue with ls -v / sort -V and strverscmp() usage

[Kamil Dudka]

I propose a simple patch for gnulib/strverscmp, which make this function much 
more useful. Note that this patch is not related to any distribution. It just 
cut off any postfix after version string.

Current version of coreutils uses strverscmp from gnulib, so if you want to 
test this patch, you need to force strverscmp from gnulib to ls or sort.

Maybe it is more useful for sort --version-sort, which has not been released 
yet. I am not sure with ls, since this tiny change has impact on known (but 
broken) ls -v behavior.


Kamil


On Wednesday 03 September 2008 12:52:57 Ondřej Vašík wrote:
> Hello,
> as reported in RH bugzilla #253817
> (https://bugzilla.redhat.com/show_bug.cgi?id=253817), there is an issue
> with ls -v (and there will be same issue with sort -V soon). Problem is
> with sorting files with extensions or dist-tags (like .tar.gz)
> because .tar.gz is more than .1.tar.gz. Therefore foo-5.0.tar.gz will be
> considered as later version than foo-5.0.1.tar.gz . As ls -v and sort -V
> now use glibc strverscmp() and this function is not going to change
> (http://sourceware.org/bugzilla/show_bug.cgi?id=3506) , I would like to
> know your opinion how to solve the issue. I see several possible ways
> how to solve it:
> 1) keep it as it is and document those limitations
> 2) to use gnulib strverscmp() for ls -v and sort -V and to modify it
> somehow to handle such cases correctly
> 3) to use/create different function for handling version sort (like
> rpmvercmp in <rpm/rpmlib.h> recommended in glibc strverscmp() bugzilla)
>
> Which way do you like? Or do you have different ideas?
>
> Greetings,
>          Ondrej Vasik

gnulib-strverscmp.patch
Description: Text Data