Re: [PATCH] tests/decode: Emit TAP

[Peter Maydell]

On Thu, 25 May 2023 at 14:11, Richard Henderson
<richard.henderson@linaro.org> wrote:
>
> On 5/25/23 03:00, Peter Maydell wrote:
> > On Wed, 24 May 2023 at 18:38, Richard Henderson
> > <richard.henderson@linaro.org> wrote:
> >>
> >> We currently print FAIL for the failure of a succ_* test, but don't
> >> return a failure exit code.  Instead, convert the script to emit
> >> Test Anything Protocol, which gives visibility into each subtest
> >> as well as not relying on exit codes.
> >>
> >> Suggested-by: Paolo Bonzini <pbonzini@redhat.com>
> >> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
> >> ---
> >>   tests/decode/check.sh | 36 ++++++++++++++++++++++++++----------
> >>   tests/meson.build     |  1 +
> >>   2 files changed, 27 insertions(+), 10 deletions(-)
> >>
> >> diff --git a/tests/decode/check.sh b/tests/decode/check.sh
> >> index 95445a0115..a3d879a099 100755
> >> --- a/tests/decode/check.sh
> >> +++ b/tests/decode/check.sh
> >> @@ -4,21 +4,37 @@
> >>
> >>   PYTHON=$1
> >>   DECODETREE=$2
> >> -E=0
> >> +E_FILES=`echo err_*.decode`
> >> +S_FILES=`echo succ_*.decode`
> >
> > If you run shellcheck on this script it produces some
> > style complaints. Notably:
> >
> >   * $(...) is better than `...`
> >   * j=$(($j + 1))  is better than j=`expr $j + 1`
> >
> > At least some of its "missing quoting" complaints are
> > also legitimate, notably on $PYTHON and $DECODETREE.
>
> "Better" in what sense?  Also, this is /bin/sh, not /bin/bash, so I'm never 
> certain what
> I'm really allowed to use.

checkpatch checks POSIX syntax if the script starts with #!/bin/sh.
(It's a pretty good tool for spotting "this thing you used
isn't actually POSIX", in fact.)

shellcheck's rationales are
https://www.shellcheck.net/wiki/SC2003 (for expr)
 -- the POSIX spec itself says "avoid expr in new scripts".
    (Also I think shell builtin arithmetic should be more efficient
    than spawning the expr binary)
https://www.shellcheck.net/wiki/SC2006 (for backticks)
 -- backticks have some awkward issues; for consistency
    I think it's better to use $() everywhere even in
    the kind of simple case where `` has no problems

configure doesn't have any backticks in it.

thanks
-- PMM