title: How can I hook into Perl's print?
body: <p>Here's a scenario.  You have a large amount of legacy scripts, all using a common library.  Said scripts use the 'print' statement for diagnostic output.  No changes are allowed to the scripts - they range far and wide, have their approvals, and have long since left the fruitful valleys of oversight and control.</p>
  
  <p>Now a new need has arrived: logging must now be added to the library.  This must be done automatically and transparently, without users of the standard library needing to change their scripts.  Common library methods can simply have logging calls added to them; that's the easy part.  The hard part lies in the fact that diagnostic output from these scripts were always displayed using the 'print' statement.  This diagnostic output must be stored, but just as importantly, processed.  </p>
  
  <p>As an example of this processing, the library should only record the printed lines that contain the words 'warning', 'error', 'notice', or 'attention'.  The below Extremely Trivial and Contrived Example Code (tm) would record some of said output:</p>
  
  <pre><code>sub CheckPrintOutput
  {
      my @output = @_; # args passed to print eventually find their way here.
      foreach my $value (@output) {
           Log-&gt;log($value) if $value =~ /warning|error|notice|attention/i;
      }
  }
  </code></pre>
  
  <p>(I'd like to avoid such issues as 'what should actually be logged', 'print shouldn't be used for diagnostics', 'perl sucks', or 'this example has the flaws x y and z'...this is greatly simplified for brevity and clarity. )</p>
  
  <p>The basic problem comes down to capturing and processing data passed to print (or any perl builtin, along those lines of reasoning).  Is it possible?  Is there any way to do it cleanly?  Are there any logging modules that have hooks to let you do it?  Or is it something that should be avoided like the plague, and I should give up on ever capturing and processing the printed output?</p>
  
  <p>Additional: This must run cross-platform - windows and *nix alike.  The process of running the scripts must remain the same, as must the output from the script.</p>
  
  <p>Additional additional: An interesting suggestion made in the comments of codelogic's answer:</p>
  
  <blockquote>
    <p>You can subclass <a href="http://perldoc.perl.org/IO/Handle.html" rel="noreferrer">http://perldoc.perl.org/IO/Handle.html</a> and create your 
      own file handle which will do the logging work. – Kamil Kisiel</p>
  </blockquote>
  
  <p>This might do it, with two caveats:</p>
  
  <p>1)  I'd need a way to export this functionality to anyone who uses the common library.  It would have to apply automatically to STDOUT and probably STDERR too.</p>
  
  <p>2)  <a href="http://perldoc.perl.org/IO/Handle.html" rel="noreferrer">the IO::Handle</a> documentation says that you can't subclass it, and my attempts so far have been fruitless.  Is there anything special needed to make sublclassing IO::Handle work?  The standard 'use base 'IO::Handle' and then overriding the new/print methods seem to do nothing.</p>
  
  <p>Final edit: Looks like IO::Handle is a dead end, but Tie::Handle may do it.  Thanks for all the suggestions; they're all really good.  I'm going to give the Tie::Handle route a try.  If it causes problems I'll be back!</p>
  
  <p>Addendum: Note that after working with this a bit, I found that Tie::Handle will work, if you don't do anything tricky.  If you use any of the features of IO::Handle with your tied STDOUT or STDERR, it's basically a crapshoot to get them working reliably - I could not find a way to get the autoflush method of IO::Handle to work on my tied handle.  If I enabled autoflush before I tied the handle it would work.  If that works for you, the Tie::Handle route may be acceptable.</p>