Hi Greg, On Tue, Jul 5, 2011 at 5:20 AM, Greg Wooledge <wool...@eeg.ccf.org> 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