With $line=<FH>, we need to check for defined-ness.

No. While there are lines read, they are defined since they have $/ attached. If $/ is undef, no point for while, since that's slurp mode. An empty string on the last line with no $/ is - no line.

I was referring to being wary when $line=<FH> is used on its own. To illustrate:


$ perl -e 'print "with_ending\nno_ending"' > a.txt
$ perl -MData::Dumper
    open(FH, "<", "a.txt") or die $!;
    my $line1 = <FH>;
    my $line2 = <FH>;
    my $line3 = <FH>;
    close FH;

    $Data::Dumper::Useqq = 1;
    print Dumper [$line1, $line2, $line3];
__END__
$VAR1 = [
          "with_ending\n",
          "no_end",
          undef
        ];
[download]


We see that there is a possibility that a line read ($line3 in this case) may return undef. That's what I meant: we need to be wary that a line read will not always return defined.

I was referring to being wary when $line=<FH> is used on its own.

Yes, but while takes care of that - and we/you were talking about a while loop, weren't you?

1.    while (<>) {
...

which is Perl short-hand for the more explicitly written version:

1.    LINE: while (defined($line = <ARGV>)) {
...

But of course,

We see that there is a possibility that a line read ($line3 in this case) may return undef.

- if you read past EOF, for instance. Then readline returns undef:

    open(FH, "<", "a.txt") or die $!;
    my $line1 = <FH>;
    my $line2 = <FH>;
    print "eof!\n" if eof FH;
    my $line3 = <FH>;
    close FH;
__END__
eof!
[download]

That's what I meant: we need to be wary that a line read will not always return defined.

That's exactly the condition when both the while($line = <FH>) { } and while(defined($line = <FH>)) { } loops terminate, so there's no difference in a while loop.