Re: [PATCH v2 2/2] t9700: do not close STDERR

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 <jrnieder@xxxxxxxxx>
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]