Beefy Boxes and Bandwidth Generously Provided by pair Networks
Syntactic Confectionery Delight

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

by tye (Sage)
on Oct 30, 2008 at 16:55 UTC ( #720515=note: print w/replies, xml ) Need Help??

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.

- tye        

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

Replies are listed 'Best First'.
Re^5: magic-diamond <> behavior -- WHAT?! (docs)
by JavaFan (Canon) on Oct 30, 2008 at 17:23 UTC
    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.

      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        

        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.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://720515]
[stevieb]: w00t! my i2c module actually works, and it works well!

How do I use this? | Other CB clients
Other Users?
Others exploiting the Monastery: (2)
As of 2017-06-22 22:51 GMT
Find Nodes?
    Voting Booth?
    How many monitors do you use while coding?

    Results (531 votes). Check out past polls.