bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Bruno Haible
Subject: Re: Issue with ls -v / sort -V and strverscmp() usage
Date: Thu, 4 Sep 2008 01:14:58 +0200
User-agent: KMail/1.5.4

Ondřej Vašík wrote:
> > Does rpmvercmp have the above property?
> 
> Similar. It separates name, epoch, version, release and architecture and
> compares those. Uses subsections of alphanum segments separated by
> non-alphanum chars. When same segment have different types, numeric is
> always considered as newer than alpha or alphanum. This solves issue
> with suffix

From this description and from its source code I can still not verify that
this function has these properties which I consider essential:

  1) cmp (s1, s2) == 0    if and only if s1 and s2 are the same,
     (otherwise the 'ls' output would not be deterministic)

  2) whenever  cmp (s1, s2) < 0 && cmp (s2, s3) < 0   then  cmp (s1, s3) < 0
     (otherwise the 'ls' output could be sorted differently if a file
     is added or removed).

  3) cmp (concat (PREFIX, s1, SUFFIX), concat (PREFIX, s2, SUFFIX)) ==
     cmp (s1, s2)
     for all PREFIXes, and for all SUFFIXes that start with a '.'.

> but changes behaviour for prefix (name) - as fully numeric
> project/file name will be considered as "newer" than alphanum
> project/file name and will be listed after alphanumeric names.

Hmm, indeed, rpmvercmp does not fulfill axiom 3: If I understand it correctly,
    rpmvercmp ("0002", "04") < 0
but rpmvercmp ("10002", "104") > 0.
I would find it more reasonable to consider zeroes at the beginning of a
segment as relevant when the segment is the first one.

Bruno





reply via email to

[Prev in Thread] Current Thread [Next in Thread]