in reply to Can't get rid of \r

Why use IO::File? Also when you read the input file, the line terminator is still there, and then you're adding another one with your join. Plus is your script running on Windows or Unix? If Unix, then the \r will be read, never gets removed, and then gets into the output.

I would handle this as follows:

open(my $in, "<", $inputfile) or die "Can't read '$inputfile': $!"; open(my $out, "<", $outputfile) or die "Can't read '$outputfile': $!"; binmode($out); while (my $line = <$in>) { $line =~ s/\r\n?/\n/g; print $out $line; } close($in) or die "Can't close '$inputfile': $!"; close($out) or die "Can't close '$outputfile': $!";
This code should work on both Unix and Windows.

I actually leave out the closes usually. Putting them in will tell you if, for instance, you had a full disk. But I usually don't worry about that.

Replies are listed 'Best First'.
Re^2: Can't get rid of \r
by rovf (Priest) on Sep 12, 2008 at 08:42 UTC
    Why use IO::File
    Eh, why not? It's part of Perl CORE, isn't it? I don't deny that there are many other ways to do I/O (with plain open or using IO::Handle for instance), but is there a drawback with IO::File?
    Also when you read the input file, the line terminator is still there, and then you're adding another one with your join.
    Indeed! I forgot to chomp! Thank you for pointing this out.
    is your script running on Windows or Unix?
    The program is supposed to be run on either Windows or Unix. I try to make it as independent as possible (I try to avoid coding two variations of the program for each platform). The input file is guaranteed to have 0x0a as line terminator, even when run under Windows.
    I actually leave out the closes usually.
    Then I would have at least to flush the buffers, otherwise other applications won't be able to access the file, until my program terminates. Also, I think they won't be able to open the file for writing while I still have it open, though this might be platform dependent. In both cases, a close makes sense IMO.
    -- 
    Ronald Fischer <ynnor@mm.st>