The while( <> ) { loop reads more data from STDIN or the file(s) in @ARGV. If you observe different behaviour, then most likely, the data from the two locations was consumed in a previous loop in the old script and is now not consumed in the new script.

A tedious but workable approach IMO is to inspect all the previous loops that consume input from STDIN, or @ARGV, by editing down (a copy of) the script until only the offending loops (or statements leaving these loops) remain.

#!/opt/oraClient/11.2.0.4/perl/bin/perl
[download]

• yeah we need context
• how are you calling it at the cli?
• are you messing with $/ or @ARGV?

/opt/oraClient/11.2.0.4/ will be $ORACLE_HOME, Oracle ships with it's own perl.Update: Oracle v12.01 ships with perl v5.14.1. They tend not ship a 'modern' perl.

  DB<33> l  72-76
72    
73:     $failures = $oldfails = 0 ;
74      
75:     while( <> ) {
76:             &assert ( (substr($_,0,4) eq "573\r") , "EC 573 is mis
+sing 573^M at start--" ) ;
  DB<34> c 75
main::unroll_and_parse_ec573(/opt/PRD/default/bin/ec2gen:75):
75:     while( <> ) {
  DB<35> x <>
  empty array
  DB<36> n
main::unroll_and_parse_ec573(/opt/PRD/default/bin/ec2gen:76):
76:             &assert ( (substr($_,0,4) eq "573\r") , "EC 573 is mis
+sing 573^M at start--" ) ;
[download]

At first sight this behaviour looks very strange. If there was any data available via <>, the command x <> would consume all of it and the loop would not be entered. I've played a bit with this setup and are able to reproduce such a thing. If <> is exhausted and the final returned undef is ignored, the next call to <> will read from STDIN, even if file names were provided via @ARGV.

This behaviour is documented in I/O Operators.

I guess there is some part in the script that ignores an undef return from <> or evaluates it in list context before the loop in question. And there are named files in addition to data from STDIN.

Update:

...the loop would not be entered.

This it not true and is not what I wanted to say. The loop is entered, but it will wait for input from STDIN.

Greetings,
-jo

$gryYup$d0ylprbpriprrYpkJl2xyl~rzg??P~5lp2hyl0p$

Thanks for the link. I think I've read it before but so many years ago, I'd forgotten how magical (or maybe devilish!) diamond operators are. I'm away from my desk right now so will take another look in the morning, but it is true that the script has ARGV processing including composite arguments and a STDIN redirection(<) on the command line, so there's every possibility that there's some quirkiness that the Perl versions have handled differently. This is the only viable patch I can come up with...

while ( <> ) {
    next if (length($_) == 0);
   .
   .
[download]

Maybe @ARGV has more files to read in?