1. If security matters to you, convert to:

   open( my $fh, "<", $file );
   if ( $fh ) { ... }
   else { log_error( "Couldn't open $file for 'reading': $!" ); }
   [download]

   If you don't log why you couldn't open the filehandle, there's no point. Plus, open() implicitly performs a -e check, so that's superfluous. Now, doing a -d check might be more useful ...
2. No, I haven't found a way to do what you're asking. I tried for an article I wrote for http://www.perl.com, but you cannot treat a bare string filename as a variable under strict, which is a pity.

... but then strict complains.

What is strict complaining about?

Good question. It was saying:

Bareword "AFILE" not allowed while "strict subs" in use at (the line where the open call is)

Is it significant that this code is in a sub that's autoloaded, where the autoload boils down to this?:

eval 'require "$fileThatContainsTheSub"';
&$varThatContainsNameOfSub;
[download]

I think it must be, because when I paste this sub into a small test script (no autoload), strict doesn't complain.

-Joe

sub open
{

    # ... some logging happens here ...

    return CORE::open($_[0], @_[1..$#_]);
}
[download]

Note that, as others have pointed out, it is a bad idea to just try to open files and not have an error check in case of failure. See perlstyle for details. Furthermore I think that it is a good idea to switch to 3-arg open: <code>open(my $AFILE, "<", $file)<code> which will keep metacharacters in $file from being wrongly interpreted.

Does this help?

use IO::File;
if (-e $file && open (my $AFILE = IO::File->new(), "<$file")) { ...
[download]

my $AFILE;
if (open ($AFILE, "<", $file)) {
  # ....
}
[download]

I got rid of the -e test, because open will fail if the file isn't there anyway.

updated to make use of 3-arg open, since it's safer.

I get no output when I run this:

use strict;
sub open {
  my $filehandle = shift;
  return CORE::open($filehandle,@_[0..$#_]);
}

my $file = $0;
my $AFILE;
if (main::open ($AFILE, '<', $file)) {
  print while <$AFILE>;
}
else {
  warn 'Failed';
}
[download]

(I do get output if the condition in the if statement is

main::open($AFILE = IO::File->new(), "<$file")
[download]

)

the lowliest monk

Surprisingly, no one managed to hit the reason why this fails. In your original code, $filehandle is referencing a global glob. With your new code, $filehandle is now ... undef. So CORE::open looks at your old code, gets the string, and populates that glob, while with the new code, it gets the reference to $filehandle and updates it.

$filehandle is now its own copy of undef, rather than a reference to it. So update your code like this:

use strict;

sub open {
    # log stuff here.
    CORE::open(@_);
}

if (-e $0 and open(my $fh, '<', $0))
{
    while(<$fh>)
    {
        print;
    }
}
[download]

Update: No changes to the above, but to address ysth's comment, all I know is that I tested the above code prior to posting, and it printed itself out. Perl 5.8.6. YMMV.

open's prototype makes just passing @_ not work. See tilly's answer for the way to do this.

Update: well, I was so sure the above wouldn't work that I didn't even try it...so I wasn't misled by the apparent success. Because Tanktalus's code doesn't use warnings, he/she is missing this:

Ambiguous call resolved as CORE::open(), qualify as such or use &

So in fact the sub never even gets called. To call a sub with the same name as a builtin, you need to specify & (or have actually overriden the builtin as described in perlsub). Modifying the code to say &open(my $fh.... gives the error I was cautioning about:

Can't use string ("3") as a symbol ref while "strict refs" in use

due to the scalar prototype on open's first argument. (@_ == 3).

Surprisingly, no one managed to hit the reason why this fails.

Sorry for tooting my own horn here, but some of us did :-) .

In your original code, $filehandle is referencing a global glob. With your new code, $filehandle is now ... undef.

Therefore, give the overriding open a non-undef lexical handle instead: open(my $AFILE = IO::File->new(), ... ). This solution has the virtue that it does not require that the overriding open be modified, something that may not be possible or desirable.

the lowliest monk