Bug #78182 for Perl-Tidy: Strange side effects on STDERR

Jeffrey, Thanks for the example. Getting STDERR output to a string is tricky because it's very easy to lose it under certain error conditions. I played with the example and found that localizing *STDERR solves part of the problem but I had to make some additional changes to the test case avoid losing the error output. I had to move the string buffer outside of the block because for certain errors it will be lost before it can be printed. Also, I had to eval the block to avoid losing everything in some cases. See the attached example. In the example I localized *STDERR in the block, but I also got the same result by localizing it inside of the Tidy.pm module. So I may localize it in the next release if I don't discover any problems, but meanwhile you could localize it in the calling routine as a workaround. But note that what you actually may want to capture is the 'errorfile', which is what would go to a .ERR file in case problems are detected in the source code, and there is no problem sending that to a string reference. Also, sending STDERR to a real file seems to work reliably. If you make any progress on this issue I would be interested. Steve

#!perl use strict; use warnings; use IO::String; use Perl::Tidy 20120701; # Trying to capture perltidy STDERR output into a string my $tidy_src = ''; my $raw_src = q{ print ['Hello World') ; }; # NOTE ERROR my $stderr_buffer = ''; # Note: must define outside of eval block my $stderr_fh = IO::String->new( \$stderr_buffer ); my $errorfile; eval { # we lose standard error output without eval # This is a good parameter set: local @ARGV = qw(-nst -nse ); # But uncomment this to generate an error condition: # push @ARGV,"-xyzzy"; local *STDERR = *STDERR; # this localization could go inside of Tidy.pm Perl::Tidy::perltidy( destination => \$tidy_src, source => \$raw_src, stderr => $stderr_fh, errorfile => \$errorfile, ); # we will never get here for some error conditions print STDOUT "May never get here if serious error\n"; }; # send something to stderr warn "Tidied code is $tidy_src"; print "\n"; print "..............Begin Error Buffer...........\n"; print "$stderr_buffer"; print "..............End Error Buffer...........\n"; print "\n"; if ($errorfile) { print "..............Begin .ERR file ...........\n"; print "$errorfile"; print "..............End .ERR file...........\n"; } else { print "..............Empty .ERR file ...........\n"; } print "\n"; print "..............Begin Tidied Code ...........\n"; print "$tidy_src"; print "..............End Tidied Code...........\n";

On Jul 3, 2012, at 5:38 PM, Steve Hancock via RT wrote: Show quoted text
What conditions do you have in mind? Are you concerned about trapping warnings from your code or from someone else's code? The former should be pretty straightforward to trap. For the latter, I've had good luck with exploiting $SIG{__WARN__}. Show quoted text
It's not lost -- the program just stops because Perl::Tidy throws an exception for those "certain errors" (like bogus options in @ARGV). But since STDERR has been globally reassigned to another handle, the error message never becomes visible. Wrapping it in an eval{} traps the exception and gives you a chance to examine the messages on that handle afterwards. But that shouldn't be mandatory. Without the eval{}, exceptions should come out on whatever *my* STDERR is, not Perl::Tidy's notion of STDERR. Show quoted text
I would probably use a scalar that points to either \*STDERR or the handle specified by the 'stderr' option (if given). Then print all the warnings to that scalar, instead of STDERR. See the attached patch for an example. That eliminates the need for an eval{} and fixes the problem with inadvertently closing the real STDERR. Show quoted text
I didn't know about the errorfile -- thanks for pointing that out! So what I really want now is to just trap stderr *and* all the log messages into one scalar. I can do that by giving 'stderr' and 'errorfile' the same IO::String. So that problem is solved :) In my use case, the distinction between stderr and the errorfile is a bit artificial. Perl::Critic feeds one file at a time to Perl::Tidy. So from that perspective, there only needs to be two output channels: 1) the tidied code; 2) everything else (errors, warnings, diagnostics, etc.) But I realize that there are other use cases too. Show quoted text
That would be my last resort. But it is good to know I can fall back to that if necessary. Thanks for making such a useful tool! -Jeff