[Top][All Lists]

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

Re: Yet Another test option

From: Bruce Korb
Subject: Re: Yet Another test option
Date: Tue, 5 Jul 2011 05:59:49 -0700

Hi Greg,

On Tue, Jul 5, 2011 at 5:20 AM, Greg Wooledge <address@hidden> wrote:
> The comment implies [2-6] but [0-6] is probably a safer bet, just in
> case someone backported the driver to an older kernel.

The code, itself, matched anything with a kernel version in the
20+something version, and my guess is that 2.6.19 ought to have
been in the same bucket -- too old.  And the comment spoke of
2.6.27 likely being recent enough, but it matched the "too old"
pattern.  In other words, the code did not match the comment,
and that was my point.

> As far as adding this sort of test to bash -- you're probably assuming
> too much.

Simplifying assumptions need to be made.  If the assumptions are not valid,
then the comparison doesn't work.  The "-V" option to the GNU sort program
is that decimal numbers sort against each other and everything else is
lexicographic.  NUL sorts before any non-NUL byte, thus "1.0" is always
before "1.0rc1" because that is indistinguishable from "1.0a", as you noted.
The simplifying assumption is that if you need to fret over trial
release numbers
then you need to figure it out for yourself.  If you want 2.6.9 so sort before
2.6.19, then you get help and you don't have to parse the numbers.

> The issue is extremely nontrivial.

The normal case is to sort full releases.  The goal in "sort -V" was to make
the usual case easy, not to make an authoritative solution to the intractable
problem. In any event, Chet doesn't think there is sufficient demand for the
facility and I certainly defer to that.  In my little world, it would be quite

Thank you.  Regards, Bruce

reply via email to

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