use IO::Scalar;

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

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?".

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.