LINE:
while (<>) {
... # your program goes here
} continue {
print or die "-p destination: $!\n";
}...
Deal with multiple files, or other advanced use cases.
I do exactly this every day with AWK. Solving exactly these kinds of problems features prominently in the AWK programming language book.
Perl is that plus more things.
And I would hereby like to remind you that every computing problem is fundamentally an input-output problem, and because of this intrinsic property, it is possible to reduce all problems in computing to input-processing-output.
Which is exactly the kind of problem AWK is designed to address.
And AWK doesn’t work with lines, it works on records, for which the fathers of the language cleverly chose the default of ‘\n’, which is reconfigurable.
Have you ever pondered the number of projects that, in addition to sh, make and common base utilities, require perl during compilation where awk could have sufficed?
As a single example, have you looked at compiling openssl without perl, using awk instead?
Whenever I see a perl prerequisite I question whether it is truly a requirement or whether other base utilities1 such as awk could replace it.
Assuming it could be removed, how much effort is one willing to expend in order to extinguish a perl dependency?
1. Some OS projects like OpenBSD make perl a base utility.
Yes, writing a build engine in AWK would be perfectly doable, but the right tool for that job is Make.
But that's not the end of it. The whole point of Perl is avoid a salad of C and shell utils. Also in many cases the moment you have to deal with >2 files at a time shell utilities begin to show their limits.
The resulting code is often far more unreadable than anything you will ever write in Perl.
In fact the whole point of Perl was Larry wall reaching the upper limits of what one could do with awk, sed and other utilities and having to use them all over the place in C. Then realizing there was a use case for a whole new language.