Now I have tested the code below from Chris Nandor with Unix Perl (Solaris)
and it works fine!!!
Has someone an idea why it does not work with MacPerl??
Beat Pfister
-----Ursprüngliche Nachricht-----
Von: Beat Pfister <[EMAIL PROTECTED]>
An: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Datum: Dienstag, 5. März 2002 08:29
Betreff: Re: [MacPerl] Edit Postscript file
>Thanks for the answer.
>
>I tested the file with your code and the result is still the same. I
>attached the infile and outfile (I hope nobody will mind).
>Perhaps the problem is that parts of the infile has "\n" and other parts
>"\r" as line ending charakter.
>
>Beat Pfister
>
>-----Ursprüngliche Nachricht-----
>Von: Chris Nandor <[EMAIL PROTECTED]>
>An: Bart Lateur <[EMAIL PROTECTED]>
>Cc: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
>Datum: Montag, 4. März 2002 20:07
>Betreff: Re: [MacPerl] Edit Postscript file
>
>
>>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).
>>
>>--
>>Chris Nandor [EMAIL PROTECTED] http://pudge.net/
>>Open Source Development Network [EMAIL PROTECTED] http://osdn.com/
>>
>
