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

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.

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
+.
[download]

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.

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        

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.

The original 20+-year old code has no "pseudo-" qualifier. Read it again and please point out where it says anything about that being "pseudocode". I don't know how much clearer it could be, but:

THE ONLY REASON THAT SNIPPET IS CALLED PSEUDOCODE IN THE CURRENT DOCUMENTATION IS THAT IT USES THE NAME ARGV FOR A FILEHANDLE AS IF A FILEHANDLE WITH THE NAME ARGV WERE NOT OTHERWISE MAGIC.

IT IS OTHERWISE THE EXACT SAME FRELLING REAL PERL CODE FROM VERSION 1.0'S MANUAL PAGE, AND WERE YOU TO SIMPLY CHANGE THE NAME OF THE SAMPLE FILEHANDLE FROM ARGV TO FRED IT WOULD WORK THE SAME AS <>.

SAYING THAT MAGIC <> WAS MEANT TO BE NOT MAGICAL BECAUSE OF THAT DISTINCTION IS MISSING THE POINT OF THE QUALIFICATION COMPLETELY.

Two-argument open has always been magic for filenames begining or ending in pipes (which are referred to (and have been referred to as such for, again, 20+-years) as just 'filenames' and not 'sooper magical pipey filenames of justice' or what have you; which means any distinction with regards to two-arg open is a misunderstanding as it is two-arg open which imparts special meaning upon filenames of a specific format). <> is magic. <> has always been magic. If you don't want the magic, you don't use the magical form either back 20+-years ago or with the current versions. But to say that it never was intended to be magic is just ahistorical revisionism, and was pointed out as such during the discussion on p5p.

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

You are now just being rude for no reason.

It really doesn't matter whether it was pseudocode, if it's exactly equivalent, or even if perl translated <> directly to that code before generating the final AST. It still doesn't mean that documentation written reflecting the use of two-arg open when there was no three-arg open means that the magic <> had to remain using the magical two-arg open. It just doesn't follow.

The reason it continued to use the magical two-arg open was a policy decision that those using it that way shouldn't have to change their programs. It's about backwards compatibility being important to people on p5p and has nothing to do with documentation that simply could have been updated. tye's argument is that saner and more secure behavior in this instance outweighs backwards compatibility of a little-used feature.

Those who have valid arguments to the contrary favor the backwards compatibility. That's it. It has nothing to do with a new Perl programmer needing to go back through every version of documentation written over the past 20 years. It has to do with backwards compatibility of the code written using the feature.

Perl 5.10.0's docs are to document Perl 5.10.0 and not to document Perl 1. There are also these documents called deltas. They explain what is different from one version to the next, and they really exist. If the policy decision about whether to make <> work with three-arg open once it was available fell the other way, the new version's docs and and delta (for example, perl51000delta or if it changed between now and then perl5120delta) could reflect how it is in the new version and how that differes from old versions, respectively.

You have wasted your block-quoted, all-capital, all-bold, fake cursing rant accusing people of misunderstanding simply because they find fault with your argument all for naught, because I still don't care if the behavior is changed or not.

Now sod off and let the adults discuss this, you insolent little bitch. There. I can be rude, too. It doesn't make my point any stronger, and your rudeness does nothing for yours, either.