Function definition changes the outward behavior of <> - perl

Question

IMPORTANT: The motivation for this question is not to solve a problem, but to understand Perl's behavior.
Consider the following toy script:
#!/usr/bin/env perl
use strict;
sub main {
#ARGV >= 2 or die "$0: not enough arguments\n";
my $arg_a = shift #ARGV;
my $arg_b = shift #ARGV;
while ( <> ) {
print "+++ $_";
}
}
main();
__END__
This script takes 2 or more arguments (which it doesn't use). All it does is to echo (with a +++ prefix) either its standard input or the contents of however many files are specified as its third, fourth, etc., arguments.
So far the code behaves as I expect it to.
Now consider this slightly modified version:
#!/usr/bin/env perl
use strict;
sub slurp {
local $/ = undef;
local #ARGV = #_;
return <>;
}
sub main {
#ARGV >= 2 or die "$0: not enough arguments\n";
my $arg_a = shift #ARGV;
my $arg_b = shift #ARGV;
my $content = slurp( $arg_a );
while ( <> ) {
print "+++ $_";
}
}
main();
__END__
This version of the script does not ignore its first argument; rather, it interprets as the path to a file, and reads its contents into the variable $content (which it subsequently ignores). Other than this, the script should behave exactly as before.
Unfortunately, this version of the script no longer echoes its stdin (though it still does echo the contents of its 3rd, 4th, etc. arguments).
I know that the problem has to do with the way the slurp function is implemented, because if I change this implementation to
sub slurp {
local $/ = undef;
open my $input, $_[ 0 ] or die "$!";
return <$input>;
}
...then the script once more echoes its stdin, when available.
I would like to understand why the first version of slurp causes the script to stop working as expected.

Answer 1

You need to exhaust the iterator (by calling it until it returns undef) before it considers using STDIN again.
sub slurp {
local $/ = undef;
local #ARGV = #_;
my $rv = <>; # Read file specified by $_[0].
1 while <>; # Exhaust the iterator.
return $rv;
}
or
sub slurp {
local $/ = undef;
local #ARGV = #_;
my $rv = "";
while (my $file = <>) {
$rv .= $file;
}
return $rv; # Concatenation of all files specified by #_.
}

Answer 2

For <> to work with STDIN it has to be called when #ARGV is empty. If there are filenames in #ARGV when <> is run they are removed from there as files are read, and then you'd need to call <> again in order to wait for the STDIN.
perl -wE'if (#ARGV) { print while <> }; print while <>' file
It is the second print while <> that waits on STDIN (without it file is printed and program exits).
That could in principle happen with your sub, if it were to read all files from #ARGV and once the control is back at the <> invocation in the main that one would then wait for STDIN.
However, your sub localizes the #ARGV (good practice!), so once it exits the global #ARGV still has what it did in the beginning.† Then while in the main reads those files (again), gets that one undef that it is due at the end of the last file, and exits.
One way to see this: remove all from #ARGV after the sub that reads input is called and before the while in main,. Then that while will wait for STDIN again, regardless of the sub. Like
perl -wE'
sub ri { local #ARGV = #_; return <> };
print for ri(#ARGV);
say"argv: #ARGV";
#ARGV=();
print while <>
' file
(A detail to note is that your example seems to take two files while the sub deals with one, so even if the sub were to use the global #ARGV (not local-ized) and remove a file from #ARGV, there'd still be one file left there to occupy the while in the main. So you still wouldn't get STDIN.)
Another way to see all this: add another print while <>, at the end; that one will wait on STDIN.
This is all described in I/O Operators (perlop), albeit it requires quite close reading.
† On local $GLOBAL_VAR; the value of $GLOBAL_VAR is copied away, and it gets restored as that scope is exited. So local protects the global variable from changes, within its scope.