in reply to Perl stops reading __DATA__ when meeting SUB character on Windows
This used to be a common problem 15 years ago. I haven't seen it lately, though.
Anyway back in the bad old days of CP/M, directory entries didn't contain the exact file length. Instead it contained the number of sectors in the file. ^Z was used as a marker at the end of text files to show where the actual end of the document was.
Various compilers and operating systems had hackarounds to emulate the behavior to "simplify" the porting of software to newer systems. In all cases, I believe it caused more trouble than it ever saved. ;^(
It sounds like you somehow have a component of your system that's in that mode. I tried to replicate it, but can't.
Anyway, to get around it, I'd expect that you could use the fixed-length record mode of reading the data, or perhaps using sysopen with the appropriate flag to ensure that it's opened in binary mode.
# Using fixed-length records is something like... do { local $/ = \100; while (<DATA>) { print OUTFILE $_; } }
Note that if you use fixed length records, you'll need to process the data further if you want it split on newlines...
...roboticus
When your only tool is a hammer, all problems look like your thumb.
|
|---|
| Replies are listed 'Best First'. | |
|---|---|
|
Re^2: Perl stops reading __DATA__ when meeting SUB character on Windows
by yfnecz (Novice) on Jan 03, 2014 at 02:31 UTC |