|laziness, impatience, and hubris|
Have you ever run a Perl script as root? If so, did you read the entire source tree of modules that get included by that script to make sure not a single one of them did:
It is a very broken tool that takes the contents of file names and lets it leak into the execution stream. Perl usually does a better job of avoiding such stupidity than many Unix tools and so I've often replaced non-Perl tools with Perl tools thinking I was improving security.
But now I have to add Perl to my list of things to "never trust". Why? Because it isn't reasonable for me to constantly keep track of exactly which modules might have been updated and might have decided to start using <>. Yes, in the real world, you have to make assumptions based on imperfect information and so you have to sometimes put your trust into things that you haven't recently disassembled and digested completely.
know what you are running when you are logged in as rootis good advice but is very black-and-white and very much "in a perfect world" thinking when used to disregard a serious flaw in software. "In a perfect world, you can know exactly what you are running when you are root." In the real world, you are reasonably cautious.
Now this <> brokenness means that I can't trust the most basic of Perl code. This is not how it should be. And it is easy to fix.
Juerd may be complaining about not having realized that <> will pass file names to the shell. I'm not. I don't care whether some people think I should have realized this or not. It is just plain stupid and broken as a design and should be changed, regardless of the existence of so-called documentation of this mis-feature.
I'm not even convinced of the validity of the "it is documented" argument. All of the documentation I recall on the subject was sufficiently vague. For example:
is equivalent to the following Perl-like pseudo code: ....So I find it perfectly reasonable to interpret that as "very much like this code" except it expects the names of files that will be read (hence them being called "filenames" repeatedly) instead of arguments to be interpretted by open as perhaps filenames, perhaps filenames w/ open modes prepended, perhaps commands to be run, etc. since doing so would mean that the code actually works. Especially since it doesn't make any sense to have "> file" nor "| command" be interpretted by <>. You can come up with unusual situations where you want to be able to put "command |" into @ARGV, but you should have to specify your intentions. - tye