http://qs1969.pair.com?node_id=477413


in reply to odd behavior with DATA section

Have you checked to make sure the file format is what perl as compiled expects? Did you look at the file with a hex editor to make sure the EOLs are as they are supposed to be?

The null could be because you have what it thinks are two end of lines back to back. They might not display correctly in windows (if it is expecting a *nix type EOL, and cygwin perl can expect that.)

In the code section, it would not cause problems since blank lines are okay. I know it is not supposed to work like that, but I have had that issue exactly bite me in the past, and there is no way any of us would see it as things are posted to the web page.

The fact that it works with the line
#    next if not $line;
uncommented makes me even more suspicious.

The last line of your submission, that it works fine on MacOS makes me wonder... Did you create the file on something other than windows? Or use a text editor for somethign other than windows? Happy hunting.

Good Luck.

Replies are listed 'Best First'.
Re^2: odd behavior with DATA section
by Nkuvu (Priest) on Jul 23, 2005 at 03:36 UTC
    After first running into the issue, I double checked line endings and tab characters in UltraEdit, using the view invisible characters bit. I should clarify, this is not Cygwin Perl, it's ActiveState Perl. I have Cygwin installed, but this is called from a Windows command prompt, not a Cygwin shell (and actually Cygwin Perl isn't even installed). The only reason I was using the Cygwin mkdir is so I didn't have to parse out the path and do repeated mkdir calls (the -p switch, if you're not familiar, creates all intermediate directories as necessary).

    The original list of files and directory structures (with the not-so-innocent names) was created by someone else in Excel. I copied the data to emacs where I created the script. For the innocently named script I copied the source code, then typed the DATA lines by hand, still in emacs. So no possiblities of pasting odd characters in there. For the OS X test I copied the source code and DATA from Perlmonks into emacs.

    So the short story is that I'm fairly sure that the line endings are correct for the operating system under test.

    But all that being said, I would not be too surprised to learn that your suspicions are accurate. I just double checked the output of the script, and noticed that the DATA line errors occur on lines 2, 4, 6, et cetera. Yet what I would expect to be line 2 in the DATA section worked fine.

    Of course now that I'm home I don't have the original script files, so I'll have to triple check line endings when I go back to work on Monday. Thanks for the input.

[reply]

      Gather more data about what perl is doing. Print out the value of $line, paying close attention to the line ending. Save the return value of chomp $line, print it, and see if it is what you expect.

[reply]
[d/l]
[select]
        Printed out the value of $line before and after chomp-ing, and it looked just like I expected. With a single newline before, and no newline after. The return value of chomp is the number of things chomped, so I expected a 1. I got a 1. No surprises there.
[reply]
[d/l]
[select]
      I have run into issues like that on UltraEdit in the past where characters did not show up in the edit screen that were there in the file. I still use UltraEdit, but I am a little more wary of things like that now.
[reply]

In Section Seekers of Perl Wisdom