[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: |
Wed, 06 Jul 2011 10:52:58 -0700 |
User-agent: |
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110616 SUSE/3.1.11 Thunderbird/3.1.11 |
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?