Re: Yet Another test option

[Bruce Korb]

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 -cV<<EOF 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?