From: "SZEDER Gábor" <szeder.dev@gmail.com>
To: Jeff King <peff@peff.net>
Cc: "SZEDER Gábor" <szeder.dev@gmail.com>,
"Johannes Sixt" <j6t@kdbg.org>, "Beat Bolli" <dev+git@drbeat.li>,
git@vger.kernel.org,
"Johannes Schindelin" <johannes.schindelin@gmx.de>
Subject: read test snippet from stdin [was: [PATCH] t3900: add some more quotes]
Date: Thu, 11 Jan 2018 12:39:28 +0100 [thread overview]
Message-ID: <20180111113928.6412-1-szeder.dev@gmail.com> (raw)
In-Reply-To: <20180110195323.GA26186@sigill.intra.peff.net>
> 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...
next prev parent reply other threads:[~2018-01-11 11:39 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-10 9:58 [PATCH] t3900: add some more quotes Beat Bolli
2018-01-10 10:33 ` Jeff King
2018-01-10 17:21 ` Johannes Schindelin
2018-01-10 17:44 ` Eric Sunshine
2018-01-10 22:38 ` [PATCH v2] " Beat Bolli
2018-01-10 23:09 ` Johannes Schindelin
2018-01-10 23:09 ` Junio C Hamano
2018-01-10 19:02 ` [PATCH] " Johannes Sixt
2018-01-10 19:43 ` Junio C Hamano
2018-01-10 19:53 ` Jeff King
2018-01-10 21:31 ` Junio C Hamano
2018-01-11 9:38 ` Jeff King
2018-01-11 11:39 ` SZEDER Gábor [this message]
2018-01-11 12:11 ` read test snippet from stdin [was: [PATCH] t3900: add some more quotes] Jeff King
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180111113928.6412-1-szeder.dev@gmail.com \
--to=szeder.dev@gmail.com \
--cc=dev+git@drbeat.li \
--cc=git@vger.kernel.org \
--cc=j6t@kdbg.org \
--cc=johannes.schindelin@gmx.de \
--cc=peff@peff.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).