As far as the code $text = <FILE> goes, look at the difference

#!/usr/bin/perl
use warnings;
use strict;

open (FILE,"< $0 ") or die "Couldn't open: $!";

# check the difference between these two lines
my $text = do {local $/; <FILE>};
#my $text = <FILE>;

close FILE;
print "$text\n";
[download]

Some filehandles you cannot seek on, like a socket filehandle. See read and sysread and run "perldoc -q file" and read all the sections. Remember, if you are on a unix style OS, you have file descriptors associated with each filehandle in /proc/$pid/fd. See How to close all open file descriptors after a fork? and close filehandles Remember, the file descriptors (numbers) in /proc/$pid/fd/ is where the real action takes place( at least on linux).... the filehandles are just convenience handles.

Alot of us Perl hackers are lazy, and don't close filehandles after use, just letting the system clean them up when the program exits. :-)

The one common gotcha encountered with the mix of unix and win32 systems, is that the 2 system have different line endings, so when the default line-by-line reading behavior is used to read a windows file on linux, proper line reading can get broken. Read "perldoc -f binmode".

and that the second case might warrant undefing the variable $/ and then maybe splitting or doing array manipulation.

Erm...no. You undefine $/ to slurp a file into a scalar; whereas @array = <FH> populates @array with lines, trailing $/ chopped off implicitly or not, according to the command line switch -l (update: wrong, implicit chomp only happens in combination of l with the n or p switch).

What I am confused about is when in a loop I have something like while(<FH>){...}, is this any different than $line=<FH> or are these granularly the same?

Run perldoc -f readline. That said, no, those are not the same: while(<FH>){...} assigns to $_, but $line=<FH> assigns to $line. Other than that, they are the same.

To delete a file we use unlink and to close a file handle we use close and then we have undef which can also close a filehandle for us, my heart tells me that using undef this way is somewhat frowned upon or sinful, is that justified?

That's not frowned upon or sinful, since a common idiom is

my @lines = do { open my $fh, '<', $file or die "$file: $!\n"; <$fh> }
+;
[download]

Perl scoping rules apply. As can be seen reading open, file handles are closed if they get out of scope (and are thus undefined implicitly). So, nothing wrong about undef $fh.

One caveat, though: You might encounter problems closing a file handle - for example flushing buffers and closing a file residing on a remote mountpoint, which became unavailable during operation of your program.

So, it is always wise to close your file handles explicitly and check the return value.

That said, no, those are not the same: while(<FH>){...} assigns to $_, but $line=<FH> assigns to $line. Other than that, they are the same.

Actually, a crucial difference is that while(<FH>){...} gets interpreted by Perl as:


    while (defined($_ = <FH>)) { ... }
[download]


which effectively ends the while loop once there are no more lines to be read from the filehandle. With $line=<FH>, we need to check for defined-ness.


my @lines = do { open my $fh, '<', $file or die "$file: $!\n"; <$fh> };

Another way:


my @lines = do { local @ARGV = $file; <> };
[download]

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.

while (<FH>) {...}
[download]

<FH>;
[download]

What I am confused about is when in a loop I have something like while(<FH>){...}, is this any different than $line=<FH> or are these granularly the same?

while (<FH>) is transformed into while (defined($_ = <FH>)).

Yes, $_=<FH> has the same granularity as $line=<FH>, whatever that means.