Re^2: Un "tie"ing a "tie"

This sounds pretty much what I want to do. I'd like to have a copy of the original "STDOUT" file handle to refer to, while I do a 'tie' on the original. I've got the tie part working, and I attempted to do a copy with

open (TagPrint::THELOG, ">&STDOUT") or die "dup: $!";
[download]

And this works quite well, BUT (repeat after me Windoze is evil!) the new file handle isn't STDOUT, and redirecting STDOUT doesn't work. How does one save "*STDOUT", which is a symbol table reference, in another variable. I can't say

THELOG = STDOUT;
[download]

then refer to 'THELOG' as if it were the original STDOUT at the point where I did the assignment. This would be "logical", but I can see it being difficult, as STDOUT is a "special" thing. It all seemed so easy. Just add a few lines to a program and it would take care of the magic. Alas, it is a bit more.

Comment on Re^2: Un "tie"ing a "tie" Select or Download Code

Replies are listed 'Best First'.
Re^3: Un "tie"ing a "tie" by dpuu (Chaplain) on Apr 18, 2006 at 01:58 UTC
% perldoc -f open ... Here is a script that saves, redirects, and restores "STDOUT" and "STDERR" using various methods: #!/usr/bin/perl open my $oldout, ">&STDOUT" or die "Can't dup STDOUT: $!"; open OLDERR, ">&", \*STDERR or die "Can't dup STDERR: $!"; open STDOUT, '>', "foo.out" or die "Can't redirect STDOUT: $!"; open STDERR, ">&STDOUT" or die "Can't dup STDOUT: $!"; select STDERR; $\| = 1; # make unbuffered select STDOUT; $\| = 1; # make unbuffered print STDOUT "stdout 1\n"; # this works for print STDERR "stderr 1\n"; # subprocesses too open STDOUT, ">&", $oldout or die "Can't dup \$oldout: $!"; open STDERR, ">&OLDERR" or die "Can't dup OLDERR: $!"; print STDOUT "stdout 2\n"; print STDERR "stderr 2\n"; [download] --Dave Opinions my own; statements of fact may be in error.	[reply] [d/l]
Re^3: Un "tie"ing a "tie" by dragonchild (Archbishop) on Apr 18, 2006 at 02:32 UTC
While "perldoc -f open" is very handy, looking at prior art would also be educational. Me, I'd look at querying CPAN for 'stdout' - the first result is probably a good one to read the source code of. In fact, you may find that using that module solves your problems. It certainly has solved a few of mine. My criteria for good software: Does it work? Can someone else come in, make a change, and be reasonably certain no bugs were introduced?	[reply]


The stupid question is the question not asked
	PerlMonks