Re^2: confusion with Chomp

[BillKSmith]

In this case, chomp removes 2 bytes at the end of the string (on Windows), the "\r\n" characters.

The behavior of chomp is independent of OS. Perl's I/O operators translate whatever our operating system uses for a newline into a perl newline character. (This conversion is not necessary in UNIX.) Even in windows, The default value for $INPUT_RECORD_SEPARATOR is "\n". As your reference specifies, this is what is removed by chomp.

The only documentation I can find for this is in binmode. The primary purpose of binmode is to turn off the newline translation. Perhaps someone can provide a more direct reference.

[Marshall]

Yes, "The behavior of chomp is independent of OS", True. Perl chomp will work fine across platforms. The "\n" in Perl generically means the "end of line" character(s).

On Windows, this means "carriage return, line feed". On Unix a single "line feed" is used, implying the "carriage return". I have a setup that allows me to use my local Windows Text editor to edit remote Unix files. When I send the file back to Unix, it can have mixed line endings (sometimes just a line feed and sometimes a carriage return and a line feed). Perl doesn't care about this and it not an issue. Some Unix utilites are not as "forgiving".

The easy way to "normalize" the line endings to the current platform:

while (<>)
{
   chomp;  #removes line endings of both varieties
   print "$_\n";  #prints with this platform's line endings.
}

My main point was that chomp() is not needed because in this case, the line ending character(s) count as white space.