Wasn't particularly trying to be difficult. I should have mentioned that I had a guaranteed file format. The <STDIN> issue is the only in that code which I can think of which pretty much has to be a bug (in that it violates expectations, even though it's doing what I asked). Of course, some would argue that perhaps one would intend that they be able to type a "." to continue and thus it's not a bug, but that would be getting pedantic, I think.

Well, I was able to *find* the <INPUT> bug, but i was not able to *spot* it. So, what I will meditate on briefly is *finding* (slow) versus *spotting* (fast).
What I did: run the code with some test data, run it, look up $/ in perlvar, realize that's not the problem, read the code again, and finally realize the problem. Total time, maybe five minutes.

So, in this case, the perlish var threw me off. If the code had been written

#!/usr/bin/perl

use strict;
use warnings;
use English;

my $file = shift || die "No file, dummy!";
open FH, "<", $file or die "Could not open ($file) for reading: $!";
local $INPUT_RECORD_SEPARATOR = "\n.\n";

while (defined (my $record = <FH>)) {
    chomp $record;
    print $record;
    <STDIN>;
}
[download]

I probably would have spotted it a lot faster. So maybe the "best practices" moral here would be to use English when doing this kind of magic thing. Even if you're a perlvar wiz, the guy maintaining your code may not be.

The second moral of the story is, with regards to finding versus spotting: if you've got a short little chunk of code like this and you know it's got a bug in it, read through every line. Read the first line. Think about it. Read the next line. Think about it. Until you've read every line. Seems like an obvious thing to do, but I am not in the habit of doing it. I am in the habit of write, try it out, check for bugs. I don't usually write then check for bugs.

But of the two morals, I think use English would probably save more time in the grand scheme of things. I may put this on my list of best practices now for everything other than $_. (I wonder whether damian conway mentioned the subject in his book?)

Knowing at least the common perlvars is important, but more generally, I think the moral of the story is to look at global special variables when something unexpected shows up.

-xdg

Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.