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

"See! Look! It was clearly meant to be this way all along! The documentation is obvious on that point! We must never change it!"

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.

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        

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