#!/bin/sh
# brintOS wasm32-hwjs: meta-networking's run-ptest with its two exec-shaped
# constructs replaced by shell builtins. Same order, same PASS:/FAIL: protocol,
# same verdicts — the difference is that this one can run at all here.
#
# 1. `tests=$(find * -type f -name 'test_suite_*')` PASSES 278 FILENAMES AS ARGV
#    AND WEDGES THE GUEST. This ptest dir holds 139 binaries plus their 139
#    .datax data files, so the shell's `*` expands to a 9210-byte argv block
#    against a `__wasm32_args_buf` of 8192 -- WASM32_ARGS_BUF_SIZE, defined
#    identically in both libcs (glibc sysdeps/wasm32/crt1-hwjs.c, musl
#    arch/wasm32/crt1_musl.c), so the cap is the arm's and not this image's.
#    HardwareJS's spawn path detects the overflow and posts
#
#      [hardwarejs] user[44] error: argv block (9210B) exceeds
#                                   __wasm32_args_buf (8192B)
#
#    and then RETURNS without starting the process — so the child never runs and
#    never exits, and run-ptest blocks in wait() forever. Not E2BIG, not a failed
#    exec: a hang, and one no timeout on this guest can break (relative timers do
#    not fire, linux-in-the-browser#120). The glob below is expanded by the
#    shell itself and execs nothing, so the same 278 names cost no argv at all.
#    BRINTOS-WORKAROUND: linux-in-the-browser#150 revisit — drop the glob rewrite
#    once an oversized argv fails the exec with E2BIG instead of wedging the
#    caller; upstream's `find` form is fine on any host where exec reports.
#
# 2. `./$f > ./$f.out 2> ./$f.err` WRITES INTO THE PTEST DIR, WHICH IS READ-ONLY
#    HERE. The rootfs is served read-only over virtio-fs at browser runtime, so
#    every redirect fails, and a failed redirect makes the shell report the case
#    FAIL whatever the program returned — all 139 of them. The captured output is
#    only read on failure anyway, so it goes to one reused temp file under
#    ${TMPDIR:-/tmp}, and the tail of a failing run is echoed inline where a
#    reader of the ptest-runner log will actually see it.
#
# The suites are run FROM the tests directory because that is where each binary's
# own test_suite_<name>.datax sits and where ../framework/data_files resolves
# from; both are compiled-in relative paths, so this cd is load-bearing.

ptestdir=$(dirname "$(readlink -f "$0")")
cd "$ptestdir"/tests || exit 1

out=${TMPDIR:-/tmp}/mbedtls-ptest.$$

for f in test_suite_*; do
    case "$f" in *.datax) continue ;; esac
    test -x ./"$f" || continue
    if ./"$f" > "$out" 2>&1; then
        echo "PASS: $f"
    else
        echo "FAIL: $f"
        sed -n 's/^/    /p' "$out" | tail -6
    fi
done

rm -f "$out"