in reply to Re^5: Unexpected result using tell/seek within the __DATA__ file
in thread Unexpected result using tell/seek within the __DATA__ file
Have a second look at my previous post. I did get 14 and 16 with the hex editor.
None of PerlIO, clib and the OS know anything of __DATA__, so they don't reporting the file positions different after the first __DATA__ is encountered.
Text after __DATA__ may be read via the filehandle PACKNAME::DATA , where PACKNAME is the package that was current when the __DATA__ token was encountered. The filehandle is left open pointing to the contents after __DATA__. It is the program's responsibility to close DATA when it is done reading from it.
Correct me if I'm wrong but the way I understand it is Perl has to compile and preprocess the program file. It reads the file until EOF or __END__ or __DATA__. According to the above section DATA is left open pointing to just after __DATA__. That means when you do a "tell DATA" like I did at the beginning of the script there is nothing for tell() to calculate: It just has to spit out the file location. Then, after reading from DATA if you do another tell DATA it has to do the math.
I just ran the script on Knoppix linux and this problem didn't show up. The seek went to the correct location and there were no partial lines printed.
I'm sorry that I couldn't explain about the offsets better. I know what I meant and it makes sense to me. I thought it was an interesting problem that others would be interested in or I wouldn't have posted it.
I've had a splitting headache all day and now that I've had some Tylenol and a snack I'm off to relax a little.
|
|---|
| Replies are listed 'Best First'. | |
|---|---|
|
Re^7: Unexpected result using tell/seek within the __DATA__ file
by ikegami (Patriarch) on Mar 12, 2011 at 06:33 UTC |