in reply to Re^2: Perl program to look into the phone directory and in case of a match, print the name along with the number
in thread Perl program to look into the phone directory and in case of a match, print the name along with the number

I was able to re-create your symptom on my Win XP platform if the last line "john" does not have a line ending. In other words if the file EOF (End Of File) occurs right after "john" instead of there being a normal "end of line" sequence of characters before the EOF.

my $line =<STDIN> is a line oriented I/O method. It returns a line when it sees the EOL (End Of Line) character sequence. If EOF happens before EOL, then it (added to post: should return the line as it does with C readline) However, in my case this returns "false" so this last "not quite complete line" is not processed.

At the moment, I do not know how to get this unusual "john" last line processed. I am sure that there is a way, but right now I don't know it. Of course in your texteditor, end the john line with "enter" and all will be fine.

Update: The symptoms that I am seeing above are on an ancient Win XP laptop. The result completely surprised me! It would be helpful if the OP can replicate my results.

Update2: Hauke D got it right at Re^3: Perl program to look into the phone directory and in case of a match, print the name along with the number

  • Comment on Re^3: Perl program to look into the phone directory and in case of a match, print the name along with the number
  • Download Code

Replies are listed 'Best First'.
Re^4: Perl program to look into the phone directory and in case of a match, print the name along with the number
by choroba (Cardinal) on Feb 14, 2017 at 21:14 UTC
    > If EOF happens before EOL, then it returns "false" so this last "not quite complete line" is not processed.

    Such a behaviour would be strange, inconsistent, and against the documentation, see readline:

    > each call reads and returns the next line until end-of-file is reached, whereupon the subsequent call returns undef .

    I'd report it as a bug.

    ($q=q:Sq=~/;[c](.)(.)/;chr(-||-|5+lengthSq)`"S|oS2"`map{chr |+ord }map{substrSq`S_+|`|}3E|-|`7**2-3:)=~y+S|`+$1,++print+eval$q,q,a,
      This is indeed strange and contrary to my C experience. No doubt about that! I just re-ran my test cases and get the same results. This is the only way I could duplicate the OP's symptoms. This did surprise me! I did not expect this result.

      I am using:
      "This is perl 5, version 20, subversion 2 (v5.20.2) built for MSWin32-x86-multi-thread-64int (with 1 registered patch, see perl -V for more detail)"
      On Win XP with all patches before end of life.

      It would be helpful if the OP or others could replicate this result on a different Windows version. Something is very odd about this. I agree! I suppose that there could be Windows problem with my ancient laptop. For a bug report, I'd like additional independent verification with exact versioning information. The more detail contained in the bug report and the easier the problem is to reproduce dramatically increases the probability that it will get fixed.