binmode(DATA) would likely solve the problem if you could do it soon enough.
My bet is that the Perl interpreter has already read far enough past __END__ / __DATA__ (reading from disk is done using buffers of several kB, even if only one line is returned to the caller) for the CTRL-Z to have caused EOF to be detected. Throwing in binmode at that point doesn't clear the EOF and you are still left with only being able to read the bytes that have been left in the handle's buffer.
You can work around this by re-opening your sourcecode file and doing binmode() immediately. But it gets tricky to seek to the exact offset for "immediately after __END__ / __DATA__", because reading w/o binmode on Win32 means "\r" characters likely got stripped and so tell is likely to be off by several bytes.
I'd just re-open the source code and read until I found "\n__END__\s*\n" or "\n__DATA__\s*\n" and then read all of the bytes after that. It isn't hard to write Perl code such that you never include "__END__" at the front of any line before the one where you used it to mark the end of your Perl code.
- tye
In reply to Re: Perl stops reading __DATA__ when meeting SUB character on Windows (buffering)
by tye
in thread Perl stops reading __DATA__ when meeting SUB character on Windows
by yfnecz
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |