http://qs321.pair.com?node_id=477463


in reply to odd behavior with DATA section

You really ought to be using __END__ instead of __DATA__. See the SelfLoader POD explanation of the way the __DATA__ is intended to be used.

Notice that the first warning is issued for the data produced from the second input record. The fact that next if not $line; allows you to avoid the warnings tells us that $line is an empty string (it could not be uninitialized, since this would terminate the while loop). This means that either the string stored in $/ is being read immediately after the end of the first input record, or that your perl build's IO is broken or confused by the record delimiters in the text. What is the value of the $/ variable?

For testing, on the line before your while() loop, insert the following assignment: 

$/ = '|';

[download]

change the text after the __DATA__ token to (the data text should be on one line): 

__DATA__
filename1:some/file/path|filename2:some/other/file/path|filename3:yet/
+another/file/path/oooh/this/one/is/long

[download]

and split with the pattern: /:/

If the warnings go away, I suspect there is a problem with your record delimiters (LF, CR/LF, etc.) or the default value of $/.

converter

Replies are listed 'Best First'.
Re^2: odd behavior with DATA section
by Nkuvu (Priest) on Jul 25, 2005 at 17:28 UTC
    You really ought to be using __END__ instead of __DATA__. See the SelfLoader POD explanation of the way the __DATA__ is intended to be used.

    Maybe you can explain this better. I read the SelfLoader POD, and it seems to indicate that __END__ indicates the end of any subroutines in the __DATA__ section. Sort of. It seems to be talking about using the __DATA__ section in packages other than main (I'm referring to sections of the POD that say "works just like __END__ in main"). So if I simply replace __DATA__ with __END__ I can't read from the section. while (my $line = <END>) doesn't work at all. If I add the __END__ token after the __DATA__ then __END__ is read in as a line.

    The SelfLoader documentation, as far as I can tell, is used to replace the AutoLoader to be able to do something. I don't write packages, so I am not understanding a lot of the POD. But my best guess is that the __DATA__ section is used for subroutines that might not be called, so you can load them only when they are used. Which doesn't do anything for me, since I'm not writing packages, I'm tossing some input onto the end of my script. I could put the information into another file, and read that, but I don't really see the point of that.

    So tell me what it is that I am missing, please.

[reply]
[d/l]

      The DATA filehandle is always used to access the text after the token, no matter if it is the __END__ or the __DATA__ token. The perldata man page gives a few important details that you should be aware of.

      I had always believed that __END__ should be used in the top-level script, with __DATA__ used only in code compiled via require or do. After re-reading the perldata man page I am of the opinion that the __DATA__ token is similar to the __END__ token but with extra features and that its use in the top-level script is fine.

      Someone please correct me if I'm wrong.

      converter

[reply]
Re^2: odd behavior with DATA section
by Nkuvu (Priest) on Jul 25, 2005 at 17:36 UTC
    Changed the text after the __DATA__ token like your example. The warnings went away. Undid the changes, the warnings did not reappear.

    So frustration of frustrations, the file seems to be "fixed." I can't reproduce the error, even after recreating the file exactly the same way I did on Friday. If I did not have documented evidence of the output I'd categorize this as temporary insanity.

[reply]

      Somewhere along the way your text was probably edited with both a Windows editor and a Mac editor, leaving alternating records with an odd combination of CR and LF on the ends, creating "invisible" empty records in the process. Merging the lines together probably removed the offending characters.

      converter

[reply]
        I wish it were that simple to diagnose. The Excel file used to create the script was created on Windows, and all editing of the script was done in emacs on Windows. The only time this script was even run on a Mac was after I got home last Friday evening and copied the script into emacs on my Mac. The script created on the Mac never left the Mac.

        Since I can't recreate the issue, I don't think there's any way I'll be able to definitively tell what was really going on. Which I find to be supremely frustrating.

[reply]

In Section Seekers of Perl Wisdom