What happens internally when you have < FH >, <>, or < * > in perl?

Question

I apologize if this question sounds simple, my intention is to understand in depth how this (these?) particular operator(s) works and I was unable to find a satisfactory description in the perldocs (It probably exists somewhere, I just couldn't find it for the life of me)

Particularly, I am interested in knowing if

a) <>

b) <*> or whatever glob and

c) <FH>

are fundamentally similar or different, and how they are used internally.

I built my own testing functions to gain some insight on this (presented below). I still don't have a full understanding (my understanding might even be wrong) but this is what I've concluded:

• <>
  • In Scalar Context: Reads the next line of the "current file" being read (provided in @ARGV). Questions: This seems like a very particular scenario, and I wonder why it is the way it is and whether it can be generalized or not. Also what is the "current file" that is being read? Is it in a file handle? What is the counter?
  • In List Context: Reads ALL of the files in @ARGV into an array
• <list of globs>
  • In Scalar Context: Name of the first file found in current folder that matches the glob. Questions: Why the current folder? How do I change this? Is the only way to change this doing something like < /home/* > ?
  • In List Context: All the files that match the glob in the current folder.
• <FH> just seems to return undef when assigned to a variable. Questions: Why is it undef? Does it not have a type? Does this behave similarly when the FH is not a bareword filehandle?

General Question: What is it that handles the value of <> and the others during execution? In scalar context, is any sort of reference returned, or are the variables that we assign them to, at that point identical to any other non-ref scalar?

I also noticed that even though I am assigning them in sequence, the output is reset each time. i.e. I would have assumed that when I do

$thing_s = <>;
@thing_l = <>;

@thing_l would be missing the first item, since it was already received by $thing_s. Why is this not the case?

Code used for testing:

use strict;
use warnings;
use Switch;
use Data::Dumper;

die "Call with a list of files\n" if (@ARGV<1);
my @whats = ('<>','<* .*>','<FH>');
my $thing_s;
my @thing_l;
for my $what(@whats){
    switch($what){
                    case('<>'){
                        $thing_s = <>;
                        @thing_l = <>;
                    }
                    case('<* .*>'){
                            $thing_s = <* .*>;
                            @thing_l = <* .*>;
                    }
                    case('<FH>'){
                            open FH, '<', $ARGV[0];
                            $thing_s = <FH>;
                            @thing_l = <FH>;
                    }

    }
    print "$what in scalar context is: \n".Dumper($thing_s)."\n";
    print "$what in list context is: \n".Dumper(@thing_l)."\n";
}

Answer 1

The <> thingies are all iterators. All of these variants have common behaviour:

• Used in list context, all remaining elements are returned.
• Used in scalar context, only the next element is returned.
• Used in scalar context, it returns undef once the iterator is exhausted.

These last two properties make it suitable for use as a condition in while loops.

There are two kinds of iterators that can be used with <>:

• Filehandles. In this case <$fh> is equivalent to readline $fh.
• Globs, so <* .*> is equivalent to glob '* .*'.

The <> is parsed as a readline when it contains either nothing, a bareword, or a simple scalar. More complex expression can be embedded like <{ ... }>.

It is parsed as a glob in all other cases. This can be made explicit by using quotes: <"* .*"> but you should really be explicit and use the glob function instead.

Some details differ, e.g. where the iterator state is kept:

• When reading from a file handle, the file handle holds that iterator state.
• When using the glob form, each glob expression has its own state.

Another part is if the iterator can restart:

• glob restarts after returning one undef.
• filehandles can only be restarted by seeking – not all FHs support this operation.

If no file handle is used in <>, then this defaults to the special ARGV file handle. The behaviour of <ARGV> is as follows:

• If @ARGV is empty, then ARGV is STDIN.

• Otherwise, the elements of @ARGV are treated as file names. The following pseudocode is executed:

  $ARGV = shift @ARGV;
  open ARGV, $ARGV or die ...; # careful! no open mode is used
  

  The $ARGV scalar holds the filename, and the ARGV file handle holds that file handle.

• When ARGV would be eof, the next file from @ARGV is opened.
• Only when @ARGV is completely empty can <> return undef.

This can actually be used as a trick to read from many files:

local @ARGV = qw(foo.txt bar.txt baz.txt);
while (<>) {
  ...;
}

Answer 2

What is it that handles the value of <> and the others during execution?

The Perl compiler is very context-aware, and often has to choose between multiple ambiguous interpretations of a code segment. It will compile <> as a call to readline or to glob depending on what is inside the brackets.

In scalar context, is any sort of reference returned, or are the variables that we assign them to, at that point identical to any other non-ref scalar?

I'm not sure what you're asking here, or why you think the variables that take the result of a <> should be any different from other variables. They are always simple string values: either a filename returned by glob, or some file data returned by readline.

<FH> just seems to return undef when assigned to a variable. Questions: Why is it undef? Does it not have a type? Does this behave similarly when the FH is not a bareword filehandle?

This form will treat FH as a filehandle, and return the next line of data from the file if it is open and not at eof. Otherwise undef is returned, to indicate that nothing valid could be read. Perl is very flexible with types, but undef behaves as its own type, like Ruby's nil. The operator behaves the same whether FH is a global file handle or a (variable that contains) a reference to a typeglob.