Re: Yet Another test option
On 7/5/11 8:59 AM, Bruce Korb wrote: 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. This is an excellent argument for a utility to perform version comparisons. Such a program could be arbitrarily complex. This feature is too new to know how it will evolve. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Yet Another test option
On 07/06/11 10:19, Eric Blake wrote: Oh, that's rather heavyweight - a command substitution and 3 pipeline components. Why not just one child process, by using sort -c and a heredoc? is_eq=false is_lt=false if test x$1 = $x2; then is_eq=true elif sort -cVEOF 2/dev/null; then $1 $2 EOF elif printf '%s\n%s\n' $1 $2 | sort -cV 2/dev/null ; then This saves the creation and removal of a temp file, too. It is cumbersome, though. Because I saw a failed attempt at a version compare in the Lustre fs code, I thought I'd suggest adding some more bulk to test because cumbersome -- errors. I would not expect sort -V and a version test to disagree. The code that coreutils uses for 'sort -V' is part of gnulib - the filevercmp module. That file (filevercmp.c) is pretty stable nowadays, with the last algorithmic change being in April 2009 and no recent complaints about unexpected behavior [...] However, I don't see any reason to add extensions to coreutils' test unless we have some agreement that we plan to add the same extension to other places like the bash builtin test at the same time. Since we've already demonstrated that version comparisons are a pretty trivial wrapper around sort, I'm not seeing much justification in favor of bloating test to make version testing builtin. bash will when coreutils does and coreutils will when bash does. OK. I don't really care a too terrible lot, but I do think that if folks writing Lustre shell scripts don't get it right, then it is an error prone comparison that probably ought to have a well architected (easy to use) solution. Perhaps just me?
Re: Yet Another test option
On 07/06/2011 10:37 AM, Bruce Korb wrote: On 07/06/11 09:03, Chet Ramey wrote: /usr/bin/test ? Do this first in the binary then migrate to bash's test? I was actually making an argument for an entirely separate utility to do this. That could be a shell script encapsulating the proper version comparison logic. which basically means a script wrapping sort -V and testing whether the arguments got reordered or not: if test X$1 = X$3 then is_eq=true ; is_lt=false else is_eq=false first=$(printf '%s\n%s\n' $1 $2 | sort -V | head -1) test X$first = X$1 is_lt=true || is_lt=false fi Oh, that's rather heavyweight - a command substitution and 3 pipeline components. Why not just one child process, by using sort -c and a heredoc? is_eq=false is_lt=false if test x$1 = $x2; then is_eq=true elif sort -cV EOF 2/dev/null; then $1 $2 EOF is_lt=true fi and if that proved insufficient, then sort -V would need an adjustment. I would not expect sort -V and a version test to disagree. The code that coreutils uses for 'sort -V' is part of gnulib - the filevercmp module. That file (filevercmp.c) is pretty stable nowadays, with the last algorithmic change being in April 2009 and no recent complaints about unexpected behavior (whereas glibc's strverscmp is locked into behavior, but that behavior raises complaints). For reference, the documentation is: /* Compare version strings: This function compares strings S1 and S2: 1) By PREFIX in the same way as strcmp. 2) Then by VERSION (most similarly to version compare of Debian's dpkg). Leading zeros in version numbers are ignored. 3) If both (PREFIX and VERSION) are equal, strcmp function is used for comparison. So this function can return 0 if (and only if) strings S1 and S2 are identical. It returns number 0 for S1 S2, 0 for S1 == S2 and number 0 for S1 S2. This function compares strings, in a way that if VER1 and VER2 are version numbers and PREFIX and SUFFIX (SUFFIX defined as (\.[A-Za-z~][A-Za-z0-9~]*)*) are strings then VER1 VER2 implies filevercmp (PREFIX VER1 SUFFIX, PREFIX VER2 SUFFIX) 0. This function is intended to be a replacement for strverscmp. */ However, I don't see any reason to add extensions to coreutils' test unless we have some agreement that we plan to add the same extension to other places like the bash builtin test at the same time. Since we've already demonstrated that version comparisons are a pretty trivial wrapper around sort, I'm not seeing much justification in favor of bloating test to make version testing builtin. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: Yet Another test option
On 7/6/11 1:52 PM, Bruce Korb wrote: I would not expect sort -V and a version test to disagree. The code that coreutils uses for 'sort -V' is part of gnulib - the filevercmp module. That file (filevercmp.c) is pretty stable nowadays, with the last algorithmic change being in April 2009 and no recent complaints about unexpected behavior [...] However, I don't see any reason to add extensions to coreutils' test unless we have some agreement that we plan to add the same extension to other places like the bash builtin test at the same time. Since we've already demonstrated that version comparisons are a pretty trivial wrapper around sort, I'm not seeing much justification in favor of bloating test to make version testing builtin. bash will when coreutils does and coreutils will when bash does. OK. I don't really care a too terrible lot, but I do think that if folks writing Lustre shell scripts don't get it right, then it is an error prone comparison that probably ought to have a well architected (easy to use) solution. Perhaps just me? Again, that's an argument for a solid solution that Lustre and others can incorporate into their projects, not something that has to go into coreutils or the shell. It could even be a C program wrapper around the module from gnulib (though those are notoriously difficult to separate from the rest of the library). Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Yet Another test option
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
Re: Yet Another test option
On Sun, Jul 03, 2011 at 11:41:02AM -0700, Bruce Korb wrote: P.S. this check is really for any version below 2.6.27: - case $LINUXRELEASE in - # ext4 was in 2.6.22-2.6.26 but not stable enough to use - 2.6.2[0-9]*) enable_ext4='no' ;; - *) . ;; and might have been done correctly with a version compare operator. case $LINUXRELEASE in # ext4 was in 2.6.22-2.6.26 but not stable enough to use 2.6.2[0-6]*) enable_ext4=no ;; ... The comment implies [2-6] but [0-6] is probably a safer bet, just in case someone backported the driver to an older kernel. See, what's really needed here is a check for the actual file system *driver version*, not the kernel version. I wouldn't know how to get that programmatically (perhaps something in /sys) ... OS issue, not a bash issue. As far as adding this sort of test to bash -- you're probably assuming too much. For instance, you may be assuming that all version strings are sequences of base-10 integers separated by periods. This is not generally the case. Version strings frequently contain a bewildering variety of barely-human-readable abbreviations, juxtapositions of letters with numbers, plus signs, minus signs, underscores, alphas, betas, release candidates, etc. Does version 1.0rc1 come before or after version 1.0? How about 1.0b1 -- is that before or after 1.0a? Is version 2.6+svn20110604 before or after version 2.6.1? The issue is extremely nontrivial.
Re: Yet Another test option
On 7/2/11 3:49 PM, Bruce Korb wrote: Hi Chet, et al., Given that sort(1GNU) now has a sort-by-version-ordering (sort -V), it would seem reasonable to do version comparisons without having to do a series of fork execs. In other words, abbreviate this: min_os_ver=` printf '2.6.27\n%s\n' $LINUXRELEASE | sort -V | head -1` if test X$min_os_ver = X2.6.27 ; then into something like this: if test 2.6.27 -Vle $LINUXRELEASE ; then or add a different operator to [[ ]] contexts? This seems like it is of really limited usefulness to be baked into the shell. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Yet Another test option
Hi Chet, On Sun, Jul 3, 2011 at 11:21 AM, Chet Ramey chet.ra...@case.edu wrote: On 7/2/11 3:49 PM, Bruce Korb wrote: Hi Chet, et al., Given that sort(1GNU) now has a sort-by-version-ordering (sort -V), it would seem reasonable to do version comparisons without having to do a series of fork execs. In other words,. into something like this: if test 2.6.27 -Vle $LINUXRELEASE ; then This seems like it is of really limited usefulness to be baked into the shell. I wouldn't know. I use it myself a bit and I am now playing with Lustre fs code where they get it wrong because it is inconvenient to get it right. After seeing that, I thought I'd suggest it. You deal with more folks with more scripting issues than I do. Your call. If you like, I could offer a patch, too. Thanks for incorporating BASH_XTRACEFD, by the way. It _has_ proven to be quite useful! Cheers - Bruce P.S. this check is really for any version below 2.6.27: - case $LINUXRELEASE in - # ext4 was in 2.6.22-2.6.26 but not stable enough to use - 2.6.2[0-9]*) enable_ext4='no' ;; - *) . ;; and might have been done correctly with a version compare operator.
Re: Yet Another test option
Bruce Korb wrote: I wouldn't know. I use it myself a bit and I am now playing with Lustre fs code where they get it wrong because it is inconvenient to get it right. After seeing that, I thought I'd suggest it. ... P.S. this check is really for any version below 2.6.27: - case $LINUXRELEASE in - # ext4 was in 2.6.22-2.6.26 but not stable enough to use - 2.6.2[0-9]*) enable_ext4='no' ;; - *) . ;; and might have been done correctly with a version compare operator. Note that on Debian systems and derivatives you can use dpkg with the --compare-versions option to perform this test. $ set -x $ dpkg --compare-versions 2.6.27 le $(uname -r) ; echo $? ++ uname -r + dpkg --compare-versions 2.6.27 le 2.6.39-2-amd64 + echo 0 0 dpkg --compare-versions 2.6.27 le $(uname -r) || enable_ext4='no' I seem to recall a similar command on Red Hat based systems but off the top of my head the details escape me. Bob
