in reply to Re: (bbfu) (tied handles) Re: Redirect dos console output to a widget
in thread Redirect dos console output to a widget

Um... It, uh, half works. :-)

#!/usr/bin/perl use Tk; $mw = MainWindow->new(-name => 'Test', -title => 'Test'); $text = $mw->Text(); $text->pack(); tie *STDOUT, 'Text::Handle', $text; tie *STDERR, 'Text::Handle', $text; print "Hello\n"; print STDERR "Hi\n"; warn "Doesn't work! :(\n"; MainLoop; package Text::Handle; use Tie::Handle; @ISA = qw/Tie::StdHandle/; sub TIEHANDLE { my $class = shift; my $widget = shift; return bless \$widget, $class; } sub PRINT { my $self = shift; $$self->insert('end', join('',@_)); }

Hrm. Looks like warn and die behave specially when it comes to STDERR. I can see good and bad points to that. :-/

It would be nice to have it more "push" oriented so that you didn't have to poll pipes (either non-blockingly, or in a seperate thread/process) but it looks like you're still going to need warn and die %SIG handlers. But that's why I wrote Tk::Carp ;-)

bbfu
Seasons don't fear The Reaper.
Nor do the wind, the sun, and the rain.
We can be like they are.

Replies are listed 'Best First'.
Re: (bbfu) Re2: (bbfu) (tied handles) Re: Redirect dos console output to a widget
by John M. Dlugosz (Monsignor) on Aug 24, 2001 at 02:40 UTC
    print "Hello\n"; print STDERR "Hi\n"; system "ls"; # what about this?
    The issue is getting an external program to "see" the redirection.

    Interesting about Warn. What exactly does it do specially with respect to STDERR?

    —John

      You're right, of course, that external programs won't honor the new STDOUT. I guess when I read "redirect _all_ of the output from my perl programs," I was thinking more of the output directly generated by the Perl program... But I suppose you would want the output from externally executed commands, too. :-) So, yes, the only choice in that case is to reopen the real STDOUT to a pipe and poll on that. *shrug*

      As for what warn does exactly with respect to STDERR... I wish I knew. ;-) I'm guessing that warn and die always write to the real STDERR so that you don't end up with situations where a warning is generated in the code that handles the tied handle (er... yeah) and so warn ends up calling the same code that generated the warning in the first place, possibly resulting in infinite recursion. I'm kind of doubting that's the case, since I think there are probably better (er, IMO) ways to avoid that situation (eg, the same way warnings generated in $SIG{__WARN__} handlers are handled). Again, all I can say is: *shrug*

      bbfu
      Seasons don't fear The Reaper.
      Nor do the wind, the sun, and the rain.
      We can be like they are.