Unquoted string "erase" may clash with future reserved word at  (#1)
    (W reserved) You used a bareword that might someday be claimed as 
+a
    reserved word.  It's best to put such a word in quotes, or capital
+ize it
    somehow, or insert an underbar into it.  You might also declare it
+ as a
    subroutine.
[download]

print {"erase"} "LOL";
[download]

However, a more modern coding style uses lexical filehandles, the 3-arg form of open and autodie to check success:

use warnings;
use strict;
use autodie;

open my $fh, '>', 'lol.txt';
print $fh 'LOL';
close $fh;
[download]

$ perl -Mdiagnostics -Mwarnings -e " open erase, '>', 'NUL'; print era
+se 1"
[download]

Unquoted string "erase" may clash with future reserved word at -e line 1 (#1)

(W reserved) You used a bareword that might someday be claimed as a reserved word. It's best to put such a word in quotes, or capitalize it somehow, or insert an underbar into it. You might also declare it as a subroutine.

use autodie;
open my($erase), '>', 'lol.txt';
print $erase "LOL";
close $erase;
[download]

I realize this is heresy, but saying “it is best to avoid BAREWORD filehandles and 2 argument open” is not as good advice as the boilerplate responses to that effect would have one believe. Advice without explanation is for children.

In particular, the examples given in the very perlintro(1) manpage that you reference indeed recommend that style right at the front:

Files and I/O

You can open a file for input or output using the open function. It’s documented in extravagant detail in perlfunc and perlopentut, but in short:

open(INFILE,  "input.txt")   or die "Can't open input.txt: $!";
open(OUTFILE, ">output.txt") or die "Can't open output.txt: $!";
open(LOGFILE, ">>my.log")    or die "Can't open logfile: $!";
[download]

...et cetera...

Considering that those are the only sorts of I/O examples that you’ll find in the perlintro(1) manpage, I don’t understand the misconnect between recommending against it and recommending for it.

The only thing really “wrong” with those cited examples out of perlintro(1) in a modern text-processing environment is that they neglect the encoding, which can be remedied with a use open pragma — amongst several other ways, such as the newish PERLIO envariable or via post-facto binmoding as it has always been done.

People have been programming Perl this way for more than two decades now. There is no need to go all PC-police on people for code that works perfectly well for their purposes. There are millions of lines of working Perl code out there that work in just this way.

Yes, there are times when more dedicated, non-shell-like constructs are more suitable.

But this is not one of them.

Here is my (humble) opinion on why it is best to avoid bareword file handles...(Update: except for STDIN, STDERR, DATA, ARGV, and the like...)

While it doesn't matter in a situation as simple as in the OP, in a non-trivial situation, if you use a lexical file handle (and 'use strict'), you can avoid the following bug:

#!/usr/bin/perl

use strict;
use warnings;

my $file = "file.txt";

CreateFile($file);

system frobnicate => $file;

sub CreateFile {
  my $f = shift;
  open(OUTPUT_FILE, ">$f") or die "Err: $!";
  for (1..100) {
    print OUTPUT_FILE "$_\n";
  }
  # blah, blah, blah...
  close OUTPUT_FH
}
[download]

This exact sort of thing happened here@work, where there is a serious lack of lexical file handle use, and took a non-zero amount of time to debug. It also failed to influence anyone's decision in choice of file handle type :-(

Advice without explanation is for children.

What's the best way, in your estimation, to explain to novice Perl 5 programmers that, given the vagaries and heuristics of S_intuit_method in toke.c, it's often easier to reason about the local and global effects of any individual unit of code if there are no barewords?

(I can count on my fingers the number of people who may be able to explain all eight rules for S_intuit_method without having to consult the code as a refresher, and I might be overestimating the number of people so qualified. If anyone, you're one of them, but I don't count on having all novices as experienced or ready to understand in full as you.)

This isn't about political correctness. It's about reducing the possibility of error in the same way that explaining that always, always, always adding a space between the file open mode and the filename in the two-argument form is as much a pattern for people to emulate as using the three-argument form. You know as well as anyone that novices tend to emulate examples without understanding them fully. Encouraging them to prefer constructs where, for example, the lack of an invisible character has no potential security flaws, seems to me to be more useful.

my $lolfile = "lol.txt";
open my $oh, ">$lolfile"
  or die "$!: $lolfile";
print $oh "LOL\n";
close $oh
  or die "$!: $lolfile";
[download]

Some Nameless One wrote:

actual filehandles should be kept transparent to the programmer — sometimes a fixed number of filehandles needs to be extended to an arbitrary number

One can also say:

actual subroutines should be kept transparent to the programmer — sometimes a fixed number of subroutines needs to be extended to an arbitrary number

As you see, precisely the same statement can be said in equal measure of subroutine names. So how come we don’t see the PC-police railing against bareword subroutine names the same way they do against bareword filehandle names? Both are global, unsigilled names in a particular package. (You can add to bareword format names to that same list, too.)

Please explain this discrepancy: why complain of one and not the other?


⋮
⋮
⋮
⋮
⋮
⋮
⋮
⋮
⋮
⋮
⋮
⋮
⋮
⋮
⋮
⋮
⋮
⋮
⋮
⋮
⋮

If Perl meant for you to never use bareword filehandles, it would deprecate them. Since it has not done so apart from those in all lowercase, they are not deprecated, and any attempt to impose any sort of One True Way™ viewpoint against something which is not deprecated by Perl is by its very nature fundamentally anti-Perlish. And that’s not good.

You may extirpate bareword handles, and for that matter dative syntax also, just as soon as you ban all such statements as:

print FH;   # send $_ to FH
print STDERR "See ya!\n";
[download]

Until such time as that should occur, kneejerk responses not to use legal and working Perl, delivered as they virtually always are without amplification and elaboration nor even explanation, seem very much out of step with the fundamentallly liberal, or at least multi-cultural, tone of basic Perl culture.

As someone who has watched that multicultural environment — that is, the founding and abiding principle of There Being More Than One Way To Do It — grow and flourish since Day 1 of Perl 1.0’s initial public release more than 23 years ago, I believe I have enough historical perspective to make the observation that Perl is not about telling people what to do or how they should do it.

For that, there’s always Python. 😱

1. For someone learning to program, starting with good habits ie modern perl makes sense
2. Read Where should I post X?. There is no need to hijack someones first post, Meditations is that way.

- arbitrary subroutine sets come into play at so high a level of abstraction that only very specific situations can imagineably need them. Multiple filehandles are an everyday occurrence. Unless you're the kind of programmer that still uses global variables for everything, it is necessary to lexically rather than bareword declare filehandles to manage their scope.

- the bareword is just a syntax. There might be rare occasions where specifying a filehandle as a bareword is needed. What is possible with a language does not mean that anything allowed is good practice. For example, proper indentation is good practice. Python enforces it Perl doesn't - this is a feature of Perl, not a licence to write unreadable code.

- Only the writer knows if his jerking of a the knee is a kneejerk reaction or a carefully considered jerking of the knee. You don't have a clue.

- Just because there is more than one way to do something doesn't mean all ways have equal merit all the time.

- You have a lot to learn!

One world, one people

• An error is an exception, which if left uncaught will terminate your program.
• A warning merely dribbles its complaints out stderr and lets your program proceed without a hiccup.

Here is how I would probably have written your program given my current boilerplate.

#!/usr/bin/env perl

use 5.10.1;
use utf8;
use strict;
use warnings;
use open        qw(:std IO :utf8);
use charnames   qw(:full);

use Carp qw(carp cluck croak confess);

##################################################

$SIG{__DIE__} = sub {
    confess "Uncaught exception: @_" unless $^S;
};

$SIG{__WARN__} = sub {
    if ($^S) { cluck   "Trapped warning: @_" }
    else     { confess "Deadly warning: @_"  }
};

END {
    unless (close STDOUT) {
        die "can't close stdout: $!";
    }
}

##################################################

my $filename = "/tmp/lol.text";

open(ERASE, "> $filename")
    || die "can't overwrite/create $filename: $!";

say ERASE "LOL \N{WHITE SMILING FACE}";

close(ERASE)
    || die "can't close $filename: $!";

exit 0;
[download]