SZEDER Gábor <szeder.dev@xxxxxxxxx> writes: > See two of the previous patches for the only such cases we had in our > test suite. However, reliably preventing this antipattern is arguably > more important than supporting these cases, which can be worked around > by only minor inconveniences. I am not sure if that inconveniences will be minor. Is this too contrived an example, for example? check () { pattern=$1 file=$2 script=./runme test_i18ngrep "$pattern" "$file" && write_script "$script" && test_expect_success "check $pattern" ' "$script" ' } check foo file <<-EOF ... test script comes here ... EOF > > Signed-off-by: SZEDER Gábor <szeder.dev@xxxxxxxxx> > --- > t/test-lib-functions.sh | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/t/test-lib-functions.sh b/t/test-lib-functions.sh > index 92ed02937..e381d50d0 100644 > --- a/t/test-lib-functions.sh > +++ b/t/test-lib-functions.sh > @@ -719,6 +719,10 @@ test_i18ncmp () { > # under GETTEXT_POISON this pretends that the command produced expected > # results. > test_i18ngrep () { > + ( read line ) && > + error "bug in the test script: data on test_i18ngrep's stdin;" \ > + "perhaps a git command's output is piped into it?" > + > if test -n "$GETTEXT_POISON" > then > : # pretend success