You should never close STDERR. This first time your program tries to print to it, it can't, which creates another error, which it can't print, which creates another error, ...

Try this instead:

use File::Spec;
open STDERR, '>', File::Spec->devnull() or exit( 1 );
[download]

Or more commonly, redirect at the shell:

  perl -le 'open AA, ">test.txt"; warn "Hello"; print AA "foo\n";' 2> 
+/dev/null
[download]

-derby

Not everyone runs Linux.

It's a sad, sad world we live in. :(

This first time your program tries to print to it, it can't, which creates another error, which it can't print, which creates another error, ...

So, closing STDERR will lead to an infinite loop if an error occurs. As is easily demonstrated:

 % perl
close STDERR;
die "ZOMG, infinite loop!";
__END__
 %
[download]

Or not. :)

Actually, writing to a closed file handle doesn't generate an error in most situations:

 % perl
close STDOUT;
print "Generate error!\n";
__END__
 %
[download]

If you enable warnings and use Perl code to write to a closed file handle, then you do generate a warning:

 % perl -w
close STDOUT;
print "Generate error!\n";
__END__
print() on closed filehandle STDOUT at - line 2.
 %
[download]

But the code that puts out that warning isn't Perl code and so doesn't generate a warning if the handle that it is writing to is closed. So not even the following causes an infinite loop:

 % perl -w
close STDOUT; close STDERR;
print "Generate error!\n";
__END__
 %
[download]

I can even go rather far trying to facilitate an infinite loop without causing one:

 % perl -w
my $loop; $SIG{__WARN__}= $loop= sub {
    $SIG{__WARN__}= $loop;
    print STDERR "Got: ", @_;
    print "Warn: ", @_;
};
close STDOUT;
print "Generate warning!\n";
die "Done.\n";
__END__
Got: print() on closed filehandle STDOUT at - line 7.
print() on closed filehandle STDOUT at - line 4.
Done.
 %
[download]

But, yes, close()ing STDERR is indeed a bad idea (for other reasons, which I covered in another reply).

- tye        

> perl -le 'open AA, ">/tmp/stderrtest"; close(STDERR); warn "Hello"; 
+close AA;' ; cat /tmp/stderrtest
>
[download]

As you can see it is not the next filehandle/file descriptor that warn() prints to, but just to file descriptor 2. When you close STDERR the newly opened file gets the now vacated file descriptor

...but just to file descriptor 2.

Still, it's a little weird that it only prints to file descriptor 2 (hard-wired), if STDERR is closed. I.e., if you reopen STDERR after fd 2 has been taken by something else, so STDERR is then associated with fd 3 for example, the warning is nicely printed to fd 3, not fd 2...

In other words, it seems this behaviour is explicitly coded somewhere as a fallback for when STDERR is closed.

Still, it's a little weird that it only prints to file descriptor 2 (hard-wired), if STDERR is closed.

Uhm, the kernel itself doesn't know anything about stderr. It's a convention used by utilities. And the convention is, "file descriptor 2 is stderr". (Just as file descriptor 1 is stdout, and file descriptor 0 is stdin).

Making the file descriptor variable would break many things, not in the least the expectation of users.