read test snippet from stdin [was: [PATCH] t3900: add some more quotes]

["SZEDER Gábor" <szeder.dev@gmail.com>]

> I've often wondered if
> our tests would be more readable taking the snippet over stdin.
> Something like:
> 
> diff --git a/t/t3900-i18n-commit.sh b/t/t3900-i18n-commit.sh
> index 9e4e694d93..09ad4d8878 100755
> --- a/t/t3900-i18n-commit.sh
> +++ b/t/t3900-i18n-commit.sh
> @@ -39,14 +39,14 @@ test_expect_success 'UTF-16 refused because of NULs' '
>  	test_must_fail git commit -a -F "$TEST_DIRECTORY"/t3900/UTF-16.txt
>  '
>  
> -test_expect_success 'UTF-8 invalid characters refused' '

Note that the test snippet started right after that last single quote,
i.e. it started with a newline.

> -	test_when_finished "rm -f \"$HOME/stderr $HOME/invalid\"" &&
> +test_expect_success 'UTF-8 invalid characters refused' - <<\EOT
> +	test_when_finished 'rm -f "$HOME/stderr $HOME/invalid"' &&

And now it starts at the beginning of this line, i.e. without that
leading neline.  This change leads to the following when run with '-v':

  expecting success: 	test_when_finished 'rm -f "$HOME/stderr $HOME/invalid"' &&
	echo "UTF-8 characters" >F &&
	printf "Commit message\n\nInvalid surrogate:\355\240\200\n" \
		>"$HOME/invalid" &&
	git commit -a -F "$HOME/invalid" 2>"$HOME"/stderr &&
	test_i18ngrep "did not conform" "$HOME"/stderr

Notice how the "expecting success" and the first line of the test ended
up in the same line.  I find this more annoying than the lack of empty
line between the colored and indented test code and the uncolored and
unindented test output.

>  	echo "UTF-8 characters" >F &&
>  	printf "Commit message\n\nInvalid surrogate:\355\240\200\n" \
>  		>"$HOME/invalid" &&
>  	git commit -a -F "$HOME/invalid" 2>"$HOME"/stderr &&
>  	test_i18ngrep "did not conform" "$HOME"/stderr
> -'
> +EOT
>  
>  test_expect_success 'UTF-8 overlong sequences rejected' '
>  	test_when_finished "rm -f \"$HOME/stderr $HOME/invalid\"" &&
> diff --git a/t/test-lib-functions.sh b/t/test-lib-functions.sh
> index 1701fe2a06..be8a47d304 100644
> --- a/t/test-lib-functions.sh
> +++ b/t/test-lib-functions.sh
> @@ -391,11 +391,32 @@ test_verify_prereq () {
>  	error "bug in the test script: '$test_prereq' does not look like a prereq"
>  }
>  
> +# Read from stdin into the variable given in $1.
> +test_read_to_eof () {
> +	# Bash's "read" is sufficiently flexible that we can skip the extra
> +	# process.
> +	if test -n "$BASH_VERSION"
> +	then
> +		# 64k should be enough for anyone...
> +		read -N 65536 -r "$1"
> +	else
> +		# command substitution eats trailing whitespace, so we add
> +		# and then remove a non-whitespace character.
> +		eval "$1=\$(cat; printf x)"
> +		eval "$1=\${$1%x}"
> +	fi
> +}

Command substitutions don't eat trailing whitespaces in general, only
trailing newlines.  POSIX:

  The shell shall expand the command substitution by executing command
  in a subshell environment (see Shell Execution Environment) and
  replacing the command substitution (the text of command plus the
  enclosing "$()" or backquotes) with the standard output of the
  command, removing sequences of one or more <newline>s at the end of
  the substitution.

Bash and dash conform to this.

How about this alternative (also adding the missing leading newline
mentioned above):

+		eval "$1='
+'\$(cat)'
+'"

The indentation is yuck, but overall perhaps a bit less hacky...