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

[tye]

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

I think you may be getting your carte blanc before your Camel. :)

I read "the Camel" and I don't believe it mentioned any such thing (probably not the same revision of "the Camel" you refer to, of course). And at the time (quite a while ago) of the coming out party of the "It is documented. Duh!" proclaimers, I don't believe it was documented well in a popular book. In any case, I never saw mention of documentation of that in books in that time frame. I'm not at all surprised that it is documented in some books by now. But I also wouldn't be totally shocked if there was a book that covered it well way back then.

But it is also true that bugs get documented in auxillary reference material. The "It is documented" is more short-hand for the "We can't change it because the standard documentation has always said that it worked that way" claim, and that is the meaning that I call "bull" on.

[JavaFan]

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
    }

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
        }
    }

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.

[tye]

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).

[Fletch]

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 . . .