in reply to redirecting STDERR, then back again

The trick is to use a local'ized version of STDERR, in the scope that interests you:

#! /usr/bin/perl -w use strict; warn "initial write to STDERR\n"; # open a scope { local *STDERR; open STDERR, '>tmp.stderr' or die "Cannot open tmp.stderr for output +: $!\n"; warn "redirected write to STDERR\n"; close STDERR; } warn "final write to STDERR\n";

You could probably get away without having the close STDERR at the end of the scope, but it's much cleaner (easier to understand what's going on) to do so explicitly.

Later: I just went and checked the example as per danger's suggestion. The technique there seems to be a little more complicated. You basically open up another file handle to cache a copy of STDERR, and then when you are finished you use that to reset the original STDERR back again. Which means there's some baggage you have to drag along with you (the previous STDERR descriptor). Using local hides this for you => one less damned thing to go wrong.

--
g r i n d e r

Replies are listed 'Best First'.
(tye)Re: redirecting STDERR, then back again
by tye (Sage) on Aug 31, 2001 at 20:22 UTC
    Using local hides this for you => one less damned thing to go wrong.

    Unfortunately, copying file descriptors using symbol table globs doesn't work very well with the underlying IO subsystem.

    You're code reopens Perl's STDERR but the original STDERR is hanging around, hidden by local. This means the file descriptor 2 is left open so that your new Perl STDERR won't be "stderr" to C routines nor to child processes. So several things that would work as expected if you used the more complicated method recommended by the documentation won't work with your method.

            - tye (but my friends call me "Tye")