Hi Greg,
On Tue, Jul 5, 2011 at 5:20 AM, Greg Wooledge 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
convenient.
Thank you. Regards, Bruce
