Set a filehandle so that prints to it are quietly skipped?

Question

This strange interest comes from expanding requirements and no time to change design (refactor). This is not good design, sure, but I need to deal with it now and hope to refactor later.

There are a few log files opened early on which are printed to throughout code. The new requirement implies that with a (new) command-line option (--noflag) one of these log files is irrelevant.

All I could do at the moment is to pad the definition (open my $fh, ...) and all uses of it (print $fh ...) with if $flag. This is clearly bad design and it is error prone (it isn't pretty either).

Is there a way to do something with $fh when it is associated with the file so that any following print $fh ... is accepted by intepreter but will result in simply not running the print, without error? (Let me imagine something like, say, $fh = VOID if $flag;.) Or, is there some NULL stream or such? All I know of are STDOUT (1), STDERR (2), and STDIN (0).

I do not want $fh to print anywhere else, ideally not even to /dev/null (if that is possible?). I did look around and couldn't find anything related. I'd appreciate being pointed to information if in fact it is out there already. Any ideas are appreciated.

PS. First question ever asked here (after years of using SO), please let me know if it's off.

UPDATE

Thanks for responses. They prompt me to add to/refine this question: Are prints marked to go to /dev/null possibly optimized, so that the 'printing' actually doesn't happen? (While I am still interested in whether it is possible to set a filehandle so to tell to Perl 'do not print here'.)

I am trying to avoid running void (print) statements, without adding conditionals.

Update/Clarification

To summarize a bit from comments (thank you!): This was not a quest for performance optimization. I completely agree with everything said in comments on this. It is simply that executing pointless statements (typically around a million) makes me uneasy. Also, I was curious about some possible dark corner of Perl that I haven't run into. (Most of this has been addressed in answers/comments.)

Answer 1

If you are on a unix operating system you can use '/dev/null'

open my $fh, '>', '/dev/null' or die 'This should never happen';

Dev null will silently accept all input.

Answer 2

Closing your filehandle

close $fh;

will make all your prints to that file handle fail. Run

no warnings 'closed';

to suppress all the warning messages that would generate (you do use warnings, right?)

Answer 3

Through magic, you could create a magical handle for which operations are always successful.

perl -e'
   {
      package Handle::Dummy;
      use Tie::Handle qw( );
      use Symbol qw( gensym );
      our @ISA = qw( Tie::Handle );
      sub new { my $fh = gensym; tie *$fh, $_[0]; $fh }
      sub TIEHANDLE { bless(\my $dummy, $_[0]) }
      sub READ  { return 1; }
      sub WRITE { return 1; }
      sub CLOSE { return 1; }
   }

   my $fh = Handle::Dummy->new();   
   print($fh "abc\n") or die $!;
   close($fh) or die $!;
   print("ok\n");
'
ok

That avoids the systems calls, but it replaces them with expensive Perl subroutine calls.

It's far simpler and more reliable^[1] to simply use /dev/null. It could very well be faster too.

---

Are prints marked to go to /dev/null possibly optimized

No. Perl doesn't know anything about /dev/null.

How slow do you think a system call is? This doesn't sound like the right thing to optimize!

---

1. The magical file handle is not associated with a system file handle, so it can't be passed to a C library, it won't survive exec, etc.

Answer 4

You can use an anonymous, temporary file (about a quarter of the way down the perldoc page) like so;

#!/usr/bin/env perl
use strict;
use Getopt::Long;

my $fh;
my $need_log = 2;
print "Intitial need_log: $need_log\n";

GetOptions('flag!' => \$need_log);
print "After option processing, need_log: ", $need_log, "\n";

if ($need_log) {
  open($fh, '>', "log.txt") or die "Failed to open log: $!\n";
}
else {
  open($fh, '>', undef);
}

print $fh "Hello World... NOT\n";
exit 0;

Here is a few runs with different use of the --flag option;

User@Ubuntu:~$ ls -l log.txt
ls: cannot access log.txt: No such file or directory
User@Ubuntu:~$ ./nf.pl
Intitial need_log: 2
After option processing, need_log: 2
User@Ubuntu:~$ cat log.txt
Hello World... NOT
User@Ubuntu:~$ rm log.txt
User@Ubuntu:~$
User@Ubuntu:~$
User@Ubuntu:~$ ./nf.pl --flag
Intitial need_log: 2
After option processing, need_log: 1
User@Ubuntu:~$ cat log.txt
Hello World... NOT
User@Ubuntu:~$ rm log.txt
User@Ubuntu:~$
User@Ubuntu:~$
User@Ubuntu:~$ ./nf.pl --noflag
Intitial need_log: 2
After option processing, need_log: 0
User@Ubuntu:~$ cat log.txt
cat: log.txt: No such file or directory
User@Ubuntu:~$

I've initialized the $need_log variable to '2' so that we can tell if it has a 'True' value as a result of the flag option being present (in which case it will have the value 1) or as a result of no mention of the flag option at all (in which case it will have the value 2).

Specifying '--noflag' triggers the else clause which has 'undef' as the third argument which creates the anonymous temporary file. This doesn't perfectly match your question of not writing at all, but if the file is temporary and you're not putting gigabytes in it, this will hopefully suffice.