in reply to Un "tie"ing a "tie"

CORE and CORE::GLOBAL. However, what you really want is to save off a handle to the original STDOUT when your STDOUT-like handle is created.

My criteria for good software:
  1. Does it work?
  2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?

Replies are listed 'Best First'.
Re^2: Un "tie"ing a "tie"
by herby1620 (Monk) on Apr 18, 2006 at 01:42 UTC
    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: $!";
    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;
    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.
      % 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";
      --Dave
      Opinions my own; statements of fact may be in error.
      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:
      1. Does it work?
      2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?