There may be an issue with "\n" in the regex sense. Perl is actually pretty "smart" about various line endings when using the file I/O layer.

I/O input is very tolerant about read (accepts any of the flavors of line ending and chomp operates fine). Perl I/O uses the context appropriate value for write. For example on Unix, printing to a file gives just <LF>, on Windows printing to a file give <CR><LF> and printing to a socket (any OS) gives <CR><LF> - the network standard text line ending.

The "\n" here may be just matching <LF>(Line Feed) instead of <CR><LF> (Carriage Return, Line Feed)? I can't think of any other way for the reported symptoms to happen.

I suppose a different regex could be used or another possibility is to open the $var for read and use the IO Layer to deal with different line endings. Of course there is a performance penalty for using this extra layer, but that may not matter.

The below code will read any type of line ending (even if they are mixed).

#!/usr/bin/perl -w
use strict;

my $input=<<END;
a,b,c,d
e,f,g,h
i,j,k,l
END

# a ref to a Perl variable can be opened for reading!
#
open IN, '<', \$input or die "cannot open var for reading";

while (<IN>)
{
   chomp;
   print;
}
#a,b,c,de,f,g,hi,j,k,l

__END__
To convert files from Windows that I transfer to Unix:
This seemingly nonsensical program converts the line endings...
when reading a Windows file on Unix...

while(<>)
{
   chomp;          # gets rid of <CR><LF> or just<LF> or just <CR>
   print "$_\n";   # new line ending is just <LF>
}
[download]

Anyway the above "nonsensical program" is how I convert a Perl script from a Windows machine for printing on a Unix machine. Perl itself does not care if the Perl source code contains mixed <LF> and <CR><LF> endings, but lpr on Unix does! So this is a simple filter that I use to get rid of any <CR> values before printing some script that might have been edited on my Windows machine and transferred to Unix.