Re: (bbfu) Re2: (bbfu) (tied handles) Re: Redirect dos console output to a widget

print "Hello\n";
print STDERR "Hi\n";

system "ls";  # what about this?
[download]

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

Comment on Re: (bbfu) Re2: (bbfu) (tied handles) Re: Redirect dos console output to a widget Download Code

Replies are listed 'Best First'.
Re: Re: (bbfu) Re2: (bbfu) (tied handles) Re: Redirect dos console output to a widget by bbfu (Curate) on Aug 24, 2001 at 03:10 UTC
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.	[reply] [d/l]

Replies are listed 'Best First'.

Re: Re: (bbfu) Re2: (bbfu) (tied handles) Re: Redirect dos console output to a widget
by bbfu (Curate) on Aug 24, 2001 at 03:10 UTC

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.

[reply]
[d/l]