On Monday, November 25, 2002, at 07:23 AM, Chris Nandor wrote:
[revisiting an old thread]In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Dan Kogai) wrote:I am talking here about taking (for example) a perl program with Mac OSOn Monday, Nov 25, 2002, at 01:05 Asia/Tokyo, Chris Nandor wrote:The bottom line was that it'd be nice to have a PerlIO filter for perl 5.8.x, so that MacPerl can execute Unix and Windows text files, and Mac OS X perl can execute Mac OS text files, etc. Patches are surely welcome! :-)One good question may be how to handle newlines in heretext, the only part that really matters because that's the only exception to the fact that newlines are nothing but whitespace from perl compiler's point of view -- oops, shebang is another. When you feed MacPerl *.pl to MacOS X, should linefeeds in heretext emit \015 or \012?
newlines, and making it run under Unix perl. In order for that to happen,
you need to translate all the CRs to LFs. That would include the CRs in the
heretext, as well as in every literal string.
I don't think it's really a good idea to translate newlines in string literals (let's lump heretext in with string literals, since that's how they function). That stuff is part of the "data" of a program, not part of the instruction set.
So by doing one mass CR->LF conversion blindly, you'd get the program to run, but it would run differently given the exact same data input. I don't think that's desirable. It's quite useful to have "\n" and File::Spec->catfile() and so on mean different things on different platforms, but literal characters changing themselves seems like quite another matter.
-Ken
