gnupic: Thread: Re: [gnupic] gputils regression tests

Hi David,

> The conditional to test for a failure is something like this:
> 
>  if ! test $tested=$passed then;
>    return 1
>  fi

"something like this"?  What is it precisely?  I don't have access to
the source at the moment.

> Maybe some bash guru can fill me in on what "test $a=$b" actually
> tests, but apparently "test 1=2" returns true.  For that problem, I
> can easily change the test to:
> 
>  if (($tested==$passed)) then;

You're then making it something other than a Bourne shell script.  I
think you need to see test(1) and consider

    $ test 1 = 1 && echo yes
    yes
    $ test 1 = 2 && echo yes
    $ test 1 -eq 1 && echo yes
    yes
    $ test 1 -eq 2 && echo yes
    $ test 1 = '  1' && echo yes
    $ test 1 -eq '  1' && echo yes
    yes
    $ test foo && echo yes
    yes
    $ test '' && echo yes
    $ test 1=2 && echo yes
    yes

bearing in mind `=' is string equality, `-eq' is a numeric comparison,
and if only one argument is given it's true if it isn't empty.

It could well be there's no problem if they've written something like

    if test "$a" = "$b"; then

Or it could well be there is a problem and you've found it.  :-)

Cheers,


Ralph.

----- Original Message ----- 
From: "Ralph Corderoy" ####@####.####
To: ####@####.####
Sent: Monday, June 11, 2007 11:00 AM
Subject: Re: [gnupic] gputils regression tests


>
> Hi David,
>
>> The conditional to test for a failure is something like this:
>>
>>  if ! test $tested=$passed then;
>>    return 1
>>  fi
>
> "something like this"?  What is it precisely?  I don't have access to the 
> source at the moment.
It's exactly that except there's an elif and else clause.  There are also a 
few other tests with different variables, but the syntax and problems are 
the same.

> You're then making it something other than a Bourne shell script.  I
> think you need to see test(1) and consider
>
>    $ test 1 = 1 && echo yes
>    yes
>    $ test 1 = 2 && echo yes
...
>    $ test 1=2 && echo yes
>    yes
Actually, I did almost exactly that.  I didn't see anything to explain the 
problem in test(1), and I think I typed exactly that last command line 
above.  But I think you've uncovered the problem now anyway: missing spaces. 
I guess "test 1=2" is equivalent to "test '1=2'"...?

> bearing in mind `=' is string equality, `-eq' is a numeric comparison,
> and if only one argument is given it's true if it isn't empty.
I wondered at first if it was somehow the wrong equality operator.  That 
wasn't the problem after all, but do you think it's still worth changing to 
'-eq' when it's fixed?  The variables are only used numerically throughout 
the script.

Of course, that still leaves the problems with the test data from Microchip 
to deal with.

David Barnett 

Hi David,

> > >  if ! test $tested=$passed then;
> > >    return 1
> > >  fi
> >
> > "something like this"?  What is it precisely?  I don't have access
> > to the source at the moment.
>
> It's exactly that except there's an elif and else clause.  There are
> also a few other tests with different variables, but the syntax and
> problems are the same.

OK, if there's no spaces around the equals sign then it's a bug since
even if $tested and $passed are empty, strlen("=") is true.

    $ test = && echo true
    true

> I didn't see anything to explain the 
> problem in test(1)

My test(1) has

       [-n] STRING
                 the length of STRING is nonzero

with the brackets around `-n' pointing out the `-n' is optional.

> But I think you've uncovered the problem now anyway: missing spaces. 
> I guess "test 1=2" is equivalent to "test '1=2'"...?

Single and double quotes are indicators to the shell how to parse the
line.  The test command doesn't see them;  they're stripped off before
hand.  So in your two cases, test's argv[1] is the address of "1=2".

> do you think it's still worth changing to '-eq' when it's fixed?  The
> variables are only used numerically throughout the script.

If they're always numeric, including being initialised to 0 if required
rather than their default of an empty string, then yes I think it's
clearer to use -eq to show you're expecting to compare numeric values.

> Of course, that still leaves the problems with the test data from
> Microchip to deal with.

That's more specialised.  I can only help with /bin/sh stuff.  ;-)

Cheers,


Ralph.