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

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".
Considering the explaination mentions a reason why the code isn't quite equivalent, and that reason isn't that the open in the pseudo-code is quite different from Perls open(), and that the authors don't sanitize the filename of special characters, I find it unreasonable to assume the open in the pseudo-code is quite different from Perls open.

"See! Look! It was clearly meant to be this way all along! The documentation is obvious on that point! We must never change it!"
The reason it isn't changed isn't because it's documented, at least, that's not all of it. There's a strong tendency on p5p to not break existing code. Bug fixes can trump that, but the view on p5p is that the current behaviour is as it was intended, and not a bug.
  • Comment on Re^9: magic-diamond <> behavior -- WHAT?! (coy)

Replies are listed 'Best First'.
Re^10: magic-diamond <> behavior -- WHAT?! (coy)
by Fletch (Bishop) on Oct 31, 2008 at 21:58 UTC

    Not to mention that the original almost 21 year old perl1 manpage version contains no such disclaimers about it being pseudo code.

    The null filehandle <> is special and can be used to emulate the behav +- ior of sed and awk. Input from <> comes either from standard input, o +r from each file listed on the command line. Here's how it works: th +e first time <> is evaluated, the ARGV array is checked, and if it i +s null, $ARGV[0] is set to '-', which when opened gives you standar +d input. The ARGV array is then processed as a list of filenames. Th +e loop while (<>) { ... # code for each line } is equivalent to unshift(@ARGV, '-') if $#ARGV < $[; while ($ARGV = shift) { open(ARGV, $ARGV); while (<ARGV>) { ... # code for each line } } except that it isn't as cumbersome to say. It really does shift arra +y ARGV and put the current filename into variable ARGV. It also use +s filehandle ARGV internally. You can modify @ARGV before the first < +> as long as you leave the first filename at the beginning of the array +.

    Not to mention that presuming as tye does above that that there was to be an implied < prepended to filenames doesn't make any sense because that would break the very explicitly documented behavior of an argument of '-' triggering the 'magic two-arg open of "-" opens STDIN' behavior (which, again, was explicitly meant to behave this way and has done so for 20+ years worth of perls.)

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

      All of which is completely in keeping with my assertion that this was an accident of implementation. I see nothing here that says "intentional" over "accidental".

      emulate the behavior of sed and awk
      ...
      or from each file listed on the command line
      ...
      The ARGV array is then processed as a list of filenames.
      ...
      put the current filename into variable ARGV
      ...
      as you leave the first filename at the beginning of the array

      I'm pretty sure running sed or awk against 'rm -rf .. |' doesn't blow away your directory.

      Thanks for the proof that for over 2 decades the intent of the feature was repeatedly documented to be non-magical, despite the implementation, the copy of the implementation in the documentation, and the documentation completely overlooking the "magical" problem.

      The documentation talks a lot about the intent. In all of that talking, the intent is always described as "filename"s and there was no mention of an intent at "magical" behavior.

      The lazy implementation uses "-" to get STDIN and the note that this thwarts the "obvious" addition of "<" to get safer behavior may be part of why the implementation didn't include such.

      - tye        

        *plonk*

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

Re^10: magic-diamond <> behavior -- WHAT?! (fix)
by tye (Sage) on Oct 31, 2008 at 19:30 UTC

    I find fixing the documentation to add "< " to the "Perl-like pseudo code" to be a miniscule fix compared to the major revamping of most of the mentions of <>, -n, and -p including many examples to make them correct. And this, of course, puts the lie to "the current behavior is as it was intended" and "the current behavior is documented". But I've said that so many times already just in this thread that I'm clearly not saying it now because I think you'll "get" it any better than the previous times. :)

    And "perl -p... *" causing "rm -rf .."? Who would ever consider that something to be "fixed"? That was clearly what was wanted all along!

    - tye