in reply to Re^4: magic-diamond <> behavior -- WHAT?! (docs)
in thread magic-diamond <> behavior -- WHAT?!

Let me quote from the Camel, second edition, dating from 1996, shortly after the release of perl 5.003. On page 54, while discussing the angle operator:
Here's how it works: the first time <> is evaluated, the @ARGV array is checked, and if it is null, $ARGV[0] is set to "-", which when opened gives you standard input. The @ARGV array is then processed as a list of filenames. The loop: 
    while (<>) {
        ...          # code for each line
    }

[download]
is equivalent to the following Perl-like pseudocode: 
    @ARGV = ('-') unless @ARGV;
    while ($ARGV = shift) {
        open(ARGV, $ARGV) or warn "Can't open $ARGV: $!\n";
        while (<ARGV>) {
            ...          # code for each line
        }
    }

[download]
except that it isn't so cumbersome to say, and will actually work. It really does shift @ARGV and put the current filename into variable $ARGV. It also uses filehandle ARGV internally -- <> is just a synonym for <ARGV>, which is magical. (The pseudocode doesn't work because it treats <ARGV> as non-magical.)
If you then switch to pages 191-194, it discusses the open function, including the effects of leading and trailing pipes in the filenames.

Replies are listed 'Best First'.
Re^6: magic-diamond <> behavior -- WHAT?! (dock)
by tye (Sage) on Oct 30, 2008 at 17:39 UTC

    Perhaps I should quote from my own node on Perlmonks, in this very thread, from October of 2008?

    There is a lot more documentation that <> shouldn't react badly to the file name I close this node with (compared to the so-called "documentation" of the magic behavior by virtue of "is equivalent to the following Perl-like pseudo code" that uses some 'open' which isn't clearly declared to be as magical as Perl's two-arg open).

    Yeah, I've heard this justification before. I've been publically laughing at it repeatedly in this thread (and for a long, long time before).

    - tye        

[reply]
[d/l]

      The equivalent code shows using what appears to me to be Perl's two-arg open. It's open(ARGV, $ARGV), and (consulting my fingers to double check) that seems to be, erm, two arguments. Yet you say you expect that particular one use of two-arg open to not be magical for just what reason?

      If that were not the case then I'd expect an explicit notation that the normal two-arg open magicalness wasn't enabled since that would be different from the normal behavior of two-arg open anywhere else. As no expectation was given to the contrary, being shown that "This works like this snippet in which there's a two-arg open" leads to the reasonable expectation that filenames passed through this construct will behave just like filenames passed to two-arg open. Again, it's doing just what the diagram on the tin shows.

      The same equivalent-for-<> code's been used back at least as far as the fourteen year old 4.0.36 manpage (back when all there was was two-arg open and you had to carry globrefs uphill both ways in the snow . . .) showing calling two-arg open identical to the code from the 2nd edition camel already shown.

      To expect <>'s file opening not to behave as two-arg open and claim it's not documented as doing so doesn't match up.

      And again: while I agree it would sane and safer to change the default, I can see why the no-backwards-compatibility-breaking-changes p5p decision was against removing 14+-year-old documented behavior.

      At any rate we're way off into #386 territory here so . . .

      The cake is a lie.
      The cake is a lie.
      The cake is a lie.

[reply]
[d/l]
[select]

        It is "Perl-like" and "pseudo code". You appear to have a great deal of faith in the effort and precision that was put into that smidge of "code" especially given the multiple layers of weasel words that were applied to it.

        Yes, I find it completely reasonable to jump from "Perl-like pseudo code" to "a very simple 'open' should not just be assumed to be more than just a pseudo-code 'open' that looks rather Perl-like and may or may not agree with a verbatum translation into real-Perl real code in any particular subtle aspect". So, if there is a possiblity that a simple <> might run off and do system("rm -rf .."), that would be something worth calling out explicitly.

        But, yes, it does hint at the possibility of magicalness in the most coy of ways. But it is also completely trounced in the amount of documentation spread over multiple places that talks about <>, -n, and -p in terms of dealing with filenames in @ARGV and showing lots of examples that clearly expect <> do deal with filenames in @ARGV and not a single example even hinting at the magicalness or any English statement even hinting at the magicalness (and nothing at all hinting at the magicalness beyond the one extra-coy connection can that be drawn after the fact, of course).

        To be frank, the lack of calling out of whether or not the "Perl-like pseudo code" 'open' was magical or not is just another demonstration of the lack of realization of this subtlety at the time of implementation and of documentation. It is more suggestive of a lack of attention to this detail which is rather the opposite of the claim "See! Look! It was clearly meant to be this way all along! The documentation is obvious on that point! We must never change it!".

        - tye        

[reply]
[d/l]
[select]
        The example pseudocode was written before three-argument open existed in Perl. I fail to see how that makes for a binding decision once the recommended non-magic open came along.

        I'm not going to get into the middle of the argument at this particular time of whether the behavior should be changed to use three-argument open or stay the way it is. I'm fairly ambivalent about this topic currently, partly because being a lone-wolf coder on smaller projects I have the luxury of knowing the contents of my directories really well. I cared more about the status of this feature when I was handling large numbers of other people's files on a server.

        I do expect people who are making strong arguments one way or the other to have strong points, though. This particular line of argument does not appear to me to be a very strong one. If I was defending your position, I'd look for some better points to make than that the old pseudocode in the documentation shows the function that was available at the time the documentation was written.

[reply]

In Section Seekers of Perl Wisdom