*Erm* It's not about your package. It suffices if some library (which you may not even call directly) is using FH to read/write a file. Suddenly your file descriptor points to some totally different file/is closed/open for writing instead of reading or something completely different.

I'm sure I don't have enough time to debug something like this. Do you?

No. Test it if you don't believe me. FHs are global to the current package, just like all other non-"special" globals.

- tye        

Well. I did test. I even installed an ancient perl 5.8.8 to make sure it hasn't been patched somewhere in between. You are right, I am wrong. I bow my head in shame.

But although I was wrong I still recommend to use variables for filehandles because a namespace collision may happen even though one carefully grepped the source code.

---

There's another issue and I misremembered it. I deliberately do something obviously stupid here to provoke the error.

#!/usr/bin/perl

use strict;
use warnings;

open say, '<', '/etc/nsswitch.conf'
  or die "Unable to open file1: $!\n";

print "Filehandle is now open!\n";

print "1: " . <say>;

exit;
[download]

This results in:

Filehandle is now open!
1: # /etc/nsswitch.conf
[download]

You'll probably also get a warning: 'Unquoted string "say" may clash with future reserved word at <script> line 8.' - something fishy is going on here. In a simple script you're likely to notice it. In a web- or GUI-driven application you probably don't.

Let's upgrade our perl and add a single line

use 5.010;
[download]

And suddenly the previously 'well-behaving' application goes boom.

Name "main::say" used only once: possible typo at <script> line 13.
Use of uninitialized value $_ in say at <script> line 8.

Can't use string ("1") as a symbol ref while "strict refs" in use at <
+script> line 8.
[download]

What?!!

'use 5.10' exports 'say()' into your namespace. And suddenly open() does not open a filehandle 'say' but a function say(). Boom. Trying to debug that in a real world application may cause some serious headscratching - it's not that obvious anymore - especially if there's nobody warning you that library 'xyz' may accidently export your favourite filehandle name in the future.