Thomas Rast wrote:
> --- a/t/t9700/test.pl
> +++ b/t/t9700/test.pl
> @@ -45,7 +45,8 @@ is($r->get_color("color.test.slot1", "red"), $ansi_green,
> "get_color");
> # Failure cases for config:
> # Save and restore STDERR; we will probably extract this into a
> # "dies_ok" method and possibly move the STDERR handling to Git.pm.
> -open our $tmpstderr, ">&STDERR" or die "cannot save STDERR"; close STDERR;
> +open our $tmpstderr, ">&STDERR" or die "cannot save STDERR";
> +open STDERR, ">", "/dev/null" or die "cannot redirect STDERR to /dev/null";
> is($r->config("test.dupstring"), "value2", "config: multivar");
> eval { $r->config_bool("test.boolother") };
> ok($@, "config_bool: non-boolean values fail");
> open STDERR, ">&", $tmpstderr or die "cannot restore STDERR";
Yeah, this makes sense.
At first I was confused: why not just let stderr go out to the console,
where a person reading can see it? But this test is meant to be run
using test_external_without_stderr, which redirects stderr to a file and
dies if it ends up getting any content.
perlfunc(1) documents the close-and-then-open trick for redirecting a
filehandle to an in-memory buffer. Here a plain reopen works fine.
So for what it's worth
Reviewed-by: Jonathan Nieder <jrnie...@gmail.com>
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
