SZEDER Gábor <[email protected]> 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 <[email protected]>
> ---
> 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
