At 14:15 -0500 3/4/2002, Chris Nandor wrote:
>At 10:57 +0100 2002.03.04, Bart Lateur wrote:
>>On Mon, 4 Mar 2002 10:37:54 +0100, Beat Pfister wrote:
>>
>>>I tried to edit postscript files with perl, but no I reconiced that perl
>>>changes the line ending charackters even if I only open the file and save it
>>>in a new file. Every "\n" is changed to an "\r", with this changes the
>>>postscript file can no logner be interpreted by a printer.
>>
>>That's strange. Is this the newest 5.6.x port? Because I'm pretty sure
>>the old MacPerl didn't behave this way. *Pretty* sure.
>>
>>Anyway, on any platform: binmode() is the solution to this kind of
>>problem. Apply it to both input and output file handle. This makes the
>>OS not alter the read or written data in any way.
>
>binmode() is a no-op on MacPerl (as it is on Unix). It can't hurt, but it
>shouldn't help. MacPerl does not change your newlines. I can't say why it
>would happen, because it clearly shouldn't, and in my tests never does.
>
> undef $/;
> open FI, "<:infile" or die $!;
> open FO, ">:outfile" or die $!;
> while (<FI>) {
> print FO $_;
> }
> close FI;
> close FO;
>
>It works fine for me, with any newlines. I suggest either the original
>code was only a portion of the actual code being used, or something else is
>causing the problem (bad input data, some other post-processing of the
>data, misdiagnosis of the actual problem, I dunno).
>
>Perhaps the actual code prints a literal "\r" expecting it to be CR, or an
>"\n" expecting it to be LF? Note that in MacPerl, \n is CR and \r is LF.
>See the perlport manpage for more information (distributed with MacPerl 5.6
>and other perls, but not with MacPerl 5.2).
Or, from the outside: did either the test input file or the test output
file get moved around via FTP using ASCII mode?
But Chris' last paragraph seems the more likely reason.
--John
--
John Baxter [EMAIL PROTECTED] Port Ludlow, WA, USA
