Beefy Boxes and Bandwidth Generously Provided by pair Networks
There's more than one way to do things
 
PerlMonks  

Angle operator

by jerryhone (Sexton)
on Oct 20, 2021 at 14:19 UTC ( #11137798=perlquestion: print w/replies, xml ) Need Help??

jerryhone has asked for the wisdom of the Perl Monks concerning the following question:

Hi brethren,
I have encountered a very strange issue, and I'm looking for advice on how to start finding the root cause... I have a VERY old script with line 1 which says
#!/opt/bin/perl5.004
To support its update to use Oracle 19c, I've changed that to
#!/opt/oraClient/11.2.0.4/perl/bin/perl
However, I now find that the behaviour has changed, and when I drill into it with the debugger I find the problem seems to be with the diamond file handle The code says
while( <> ) { &assert ( (substr($_,0,4) eq "573\r") , "blah, blah...
What I'm seeing is that in the original Perl, I am not going into the while loop, but with the new version, I am! Command line is identical for each version, environment is identical for each version - the only change is line 1! Any thoughts on how I can get to the bottom of this...?

Replies are listed 'Best First'.
Re: Angle operator
by Corion (Patriarch) on Oct 20, 2021 at 14:30 UTC

    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.

Re: Angle operator
by BillKSmith (Monsignor) on Oct 20, 2021 at 16:55 UTC
    Perhaps an input file specified on your command line failed to open under your new script. You can easily verify this by intentionally specifying a file which does not exist and testing for exactly the same error. If so, try specifying the full path to the required file. This probably will not help, but it is so easy that it is worth a try.
    Bill
Re: Angle operator
by perlfan (Vicar) on Oct 20, 2021 at 21:18 UTC
    What version of perl is this,
    #!/opt/oraClient/11.2.0.4/perl/bin/perl
    Looks like one bundled with oraClient, whatever that is?
    • 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.

Re: Angle operator
by jerryhone (Sexton) on Oct 20, 2021 at 16:01 UTC
    In the debugger
    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--" ) ;
    I've restarted the process and continued directly to line 75 - the 'while' loop I've then dumped out the content of the STDIN file handle - it's empty. Then 'next' and I'm in the loop - why!

      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); . .

      Maybe @ARGV has more files to read in?

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://11137798]
Approved by philipbailey
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others drinking their drinks and smoking their pipes about the Monastery: (6)
As of 2022-05-16 09:48 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    Do you prefer to work remotely?



    Results (62 votes). Check out past polls.

    Notices?