open(my $fh, "<", "file.txt") or die "wft?"
my @lines = <$fh>;
lines is now an array of lines, you can join them into a single string if you want. open(my $fh, "<", "file.txt") or die "wft?"
my @lines = <$fh>;
lines is now an array of lines, you can join them into a single string if you want. open(my $fh, "<", "file.txt") or die "Error reading file: $!";
my @lines = <$fh>;
To slurp into a string rather than an array of lines: open(my $fh, "<", "file.txt") or die "Error reading file: $!";
my $s = join('',<$fh>); my $data = `cat $file`;
Some folks dislike the useful use of cat, but anyone who's ever read a shell script will recognize the idiom. And it's a trivial one-liner much simpler still than the python code .For one-time uses there's not a problem. However, if you find yourself writing what amount to shell scripts in Perl, you might be better off just writing shell scripts.
Broadly, your argument seems to be that spawning processes in the external environment[1] (which, admittedly, is inherently nonportable) is a Bad Thing in perl, and that we shouldn't do it. When I rephrase it like that, does it sound as poo-flinging crazy to you as it does to me?
[1] Let's be honest: a working "cat" is pretty much the single most portable thing you can put between the backticks. If you won't allow this, what will you permit?
My point was more that slurping a file without spawning another process is already quite easy in perl. That method of slurping contradicts common patterns like "while (<$fh>)". I'm not saying it's strictly wrong or even bad, just not necassarily the best option.