in reply to Re: Problem with <STDIN>
in thread Problem with <STDIN>

No, that's completely wrong. chomp removes what's in $/ from the end of its arguments. $/ is equal to \n (by default) in Windows, so chomp only removes \n (by default) on Windows too.

die("\\n ne LF\n") if "abc\n" ne "abc\x0A"; print("\\n eq LF\n"); $s = "abc"; $l1 = length($s); chomp($s); $l2 = length($s); if ($l1 - $l2 == 0) { print("abc unchanged\n"); } else { print("???\n"); } $s = "abc\n"; $l1 = length($s); chomp($s); $l2 = length($s); if ($l1 - $l2 == 1) { print("\\n removed from abc\\n\n"); } elsif ($l1 - $l2 == 0) { print("abc\\n unchanged\n"); } else { print("???\n"); } $s = "abc\r\n"; $l1 = length($s); chomp($s); $l2 = length($s); if ($l1 - $l2 == 2) { print("\\r\\n removed from abc\\r\\n\n"); } elsif ($l1 - $l2 == 1) { print("\\n removed from abc\\r\\n (\\r kept)\n"); } elsif ($l1 - $l2 == 0) { print("abc\\r\\n unchanged\n"); } else { print("???\n"); } __END__ ActivePerl v5.8.0 on WinXP -------------------------- \n eq LF abc unchanged \n removed from abc\n \n removed from abc\r\n (\r kept)

Perl translates CR+LF to LF for you when you read from a file in Windows (unless you use binmode on that handle). Similarly, Perl translates LF to CR+LF when writting to a file handle in Windows (unless you use binmode on that handle).

The reason to use chomp is to handle the case where a line without the line terminator is read in. chop would fail to perform as desired there, but chomp wouldn't. That has nothing to do with CR+LF vs LF.

Update: Added underlined text to clarify my intended message, at GrandFather's recommendation.

Replies are listed 'Best First'.
Re^3: Problem with <STDIN>
by GrandFather (Saint) on Jun 28, 2006 at 20:20 UTC

    It's not that chop fails, as it removes the last character regardless of what that character is. You could interpret that to mean that chop "fails to DWIM", but it hasn't failed, just not met the programmer's expectations.


    DWIM is Perl's answer to Gödel