Note that this is a theoretical race problem. The code could potentially run the test and determine that the file is readable, writeable, whatever.

In the intervening period between the test and the moment you attempt to open the file, the permissions might have changed, or the file itself may no longer be around.

It's the classic resource acquisition problem. Sometimes, no amount of testing can tell you whether something will succeed. All you can do is try it, and see what happens. So, to a certain extent, the technique shown in the OP is the best way to go.

Yup, agreed, i would s/theoretical// as there is an actual risk, and it can happen...

To handle the negative case, one could include a die handler in the open statement to make sure everything is nice and graceful.

If I add an if (open(FH, $path) or die "$!") { doesn't that kill the application?

I still want it to print out the rest of the webpage.

Update2: Nevermind.

Not really; many platforms allow additional settings to provide/forbid access not taken into account by -r, so the easiest way is actually to try the open. The problem with that is that some other error may crop up and you'll never find out about it because you are ignoring all errors; you may want to ignore only permissions errors and carp on any others:

use Errno;
if (open $fh, "<", "foo/bar/baz") {
   ...
} elsif ($!{EPERM}) {
   print "no go!\n";
} else {
   print "error opening foo/bar/baz: $!";
}
[download]

Of course, to be really uptight about complaining about unexpected errors but ignoring lack of read permission to the file, you should go on to make sure the EPERM didn't result from lack of access to one of the directories traversed, but I'm not going there...