Beefy Boxes and Bandwidth Generously Provided by pair Networks
Problems? Is your data what you think it is?

Re: chomp() is confusing

by davorg (Chancellor)
on May 15, 2006 at 08:21 UTC ( #549395=note: print w/replies, xml ) Need Help??

in reply to Why chomp() is not considering carriage-return

In addition to the excellent advice given by other monks above, you might also find it useful to read the section on newlines in perldoc perlport.


"The first rule of Perl club is you do not talk about Perl club."
-- Chip Salzenberg

Replies are listed 'Best First'.
Re^2: chomp() is confusing
by Anonymous Monk on Sep 02, 2011 at 19:13 UTC
    Of course it depends on what you know about your input data: for most purposes s/[\r\n]+// will do the job as long as you can guarantee no \r or \n embedded in the lines. Monks might object that s/[\r\n]+$// is faster, being anchored, however reading a Windows file on a Mac there may be a possibility of splitting the \n onto the next line - I couldn't say.
      As of today using Strawberry Perl (64bit), Perl doesn't automatically adapt chomp at all to the platform nor converts automatically the carriage return from files that are read. For me, it always just remove \n, and that's all. My solution: either change the special var as suggested above, or use your own chomp with a substitution regexp: s/(\n|\r)//g Or of course, change the carriage return of all your files.
        As of today using Strawberry Perl (64bit), Perl doesn't automatically adapt chomp at all to the platform nor converts automatically the carriage return from files that are read.

        But Perl doesn’t work like that. As ikegami explained in his post up-thread, removal of the carriage return (CR) character occurs before the string is ever fed to chomp. See the section Defaults and how to override them in PerlIO. On Windows platforms the IO layers default to unix (the lowest level layer) plus a crlf layer on top of this. This crlf is:

        A layer that implements DOS/Windows like CRLF line endings. On read converts pairs of CR,LF to a single "\n" newline character. On write converts each "\n" to a CR,LF pair.

        So, it is the crlf layer that converts each literal 0d0a to Perl’s logical newline "\n" (0a), and this happens as each line of the file is read in.

        The input record separator, $/, defaults to "\n" (0a), Perl’s logical newline character, regardless of the platform. And chomp($string) removes from the end of $string the character(s) (if any) currently assigned to $/. Which all works out fine, because on Windows each CRLF has already been converted into a LF by the crlf IO layer before chomp comes into play.

        Now, I can’t test Strawberry Perl (64bit) as I don’t have a 64-bit OS. However, if the latest 64-bit version of Strawberry Perl does handle CRs incorrectly, it’s likely the difference is due to a change in the default IO layers. It’s unlikely to be in any way related to the implementation of the chomp function, for the reasons outlined above. I can confirm that the 32-bit versions of Strawberry Perl 5.14.2 and 5.16.0 (64int) treat carriage returns identically when reading in a text file under Vista.

        Of course, the above applies only to text files. If binmode is applied to a file handle before it is read, conversion is suppressed, CRs are retained, and chomp has no effect on these CRs (unless $/ has been re-assigned).

        Update: Try specifying the input layer explicitly:

        open(my $fh, '<:crlf', $filename) or die ...

        Athanasius <°(((><contra mundum

        Good news, as of Perl 5.1, you can use the \R $line =~ s/\R//g; It will figure it out.

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://549395]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others exploiting the Monastery: (5)
As of 2022-05-24 21:46 GMT
Find Nodes?
    Voting Booth?
    Do you prefer to work remotely?

    Results (84 votes). Check out past polls.