I boggle everytime I see this defended as a feature. Why is it a feature that:
is broken?? It doesn't process the files matching * as any sane person would expect it to. It can't even handle files that have leading spaces in their names. It is quite simply stupid, dangerous, and counter-intuitive.
Sure, it is cute to have a feature where you can load up @ARGV with qw( >this >that >the >other ) and have the "read files" operator create a bunch of empty files for you. You can even go out of your way to come up with a useful invocation of it.
But that shouldn't come at the expense of breaking the default case of dealing with @ARGV coming from the command line that contains a list of file names! If you want to play such games, then you should be allowed to but you shouldn't break the basic functionality of perl -ne '...' * in order to support that! Especially not in a way that warrants a CERT advisory!
I'd patch this so that the "magic open" is applied to <> iff use open IN=>':magic'; were in effect. I started down that road when I started a patch to fix use open IN=>':raw'; to work on <> because it is currently impossible to use binmode with <>.
But the reaction from p5p made me think that my efforts would be wasted as such a patch would not be accepted.
Someone really should have CERT file a report on this. It is a serious security bug in Perl that should be fixed and should be advertised more.
How this works is clearly an accident of implementation and not an intentional design. The fact the people have come up with creative uses for this accident doesn't mean that the tons and tons of legitimate uses of <> (in an attempt to read the files named in @ARGV) should be left broken just because we didn't realize that they were broken when we were telling people to use <> to iterate over the lines in files named in @ARGV.
Those who really feel that this misfeature should continue to be the default behavior need to update tons of documentation that encourages the use of <> for iterating over a list of files matched by a wildcard.
The fact is that *both* magical and non-magical expectations for <> are documented. Any place that mentions perl -ne '...' * is documenting the sane behavior that was always expected/intended and this is by far the most common desired behavior when <> is used.
Making <> sane by default (instead of magical) would fix more existing code than it would break! And the code that would be broken would be simple to fix (add a single use open IN=>':magic';) and would be code that was written with awareness of how strange <> can behave and so would more be likely to learn of the need for this change.
It isn't hard to find nodes by people who claim to not be surprised by this mis-feature that contain code that seems to clearly indicate that they don't expect magical behavior. I did a quick super search for nodes by merlyn that mention "local" and "*ARGV" and I found a bunch of uses of <> that don't set @ARGV= "< input.file" nor mention the dangers of not doing that.
And if you change all of your code so @ARGV is always populated with "< $filename", then $^I becomes useless! How $^I works clearly indicates that the writers of Perl did not take magical open into account during the design. We just need to fix it, not document how it has always been this way and shame on you for not realizing it (we didn't realize it either, but we refuse to admit that it was a mistake).- tye