Re (tilly) 1: Redirecting STDOUT to a variable via eval?

Just a quick hack, requires 5.004 or better:

use IO::Scalar;

sub var_eval {
  local *FH;
  my $fh;
  tie (*FH, 'IO::Scalar', \$fh);
  $saved = select FH; 
  eval shift;
  select $saved;
  $fh;
}
[download]

UPDATE
This requires (obviously) IO::Scalar.

Comment on Re (tilly) 1: Redirecting STDOUT to a variable via eval? Download Code

Replies are listed 'Best First'.
Re (tilly) 1: Redirecting STDOUT to a variable via eval? by mr.nick (Chaplain) on Feb 12, 2001 at 09:51 UTC
Hm. This seems to act strangely. It appears that anything externally spawned from the eval's block doesn't inherit the new STDOUT (which is what the `select $fh` sets, correct?). For example, the following doesn't work `$eval='system("ls")'; $result=var_eval($eval);` [download] I'm not overly concerned about this, but am kind of curious as to why it works this way. I can't seem to wrap my brain around "why?".	[reply] [d/l] [select]
Re (tilly) 3: Redirecting STDOUT to a variable via eval? by tilly (Archbishop) on Feb 12, 2001 at 10:20 UTC
That is because tie only is working on Perl IO. A system command hands the file descriptor for STDOUT to the command being launched, which knows nothing about Perl's IO. The same gotcha exists for working with C extensions that do their own printing. For one solution you can do a piped open like this: `use IPC::Open3; sub piped_cmd { local TO; local FROM; open3 (\TO, \FROM, \*FROM, "perl") or die "Cannot launch perl: $!" +; print TO @_, "\n__END__\n"; local $/; <FROM>; }` [download] (That is portable, Windows and Unix.) Note that doing things that way does not give access to various things that you have defined in your script. If you want that you are probably out of luck because all of the methods that I know of for IO games (select, tie, etc) work at the Perl level, and leave the C file-descriptors alone. But then when you call system the program works by file descriptor. :-( This could be construed as a bug.	[reply] [d/l]