gnupic: Re: [gnupic] gputils regression tests
Subject:
Re: [gnupic] gputils regression tests
From:
Ralph Corderoy ####@####.####
Date:
12 Jun 2007 10:54:43 +0100
Message-Id: <20070612095408.A80C014A7D0@blake.inputplus.co.uk>
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.
