use Data::Dumper;
local $Data::Dumper::Useqq = 1; # will also print \r, \n etc.
print Dumprt $var;
[download]

I expect both prints to print out the same. After all, the chomp has nothing to do, as there will be no newlines left after the split.

$var is taking input from an HTML text area. It goes something like this:

a,b,c,d
e,f,g,h
i,j,k,l
[download]

There is a carriage return at the end of each line. @arr1 before the chomp should like like above when printed out. However, I would expect that after the chomp that @arr1 would print like this:

a,b,c,d e,f,g,h i,j,k,l

But it doesn't, it prints like the first example.

There is a carriage return at the end of each line. @arr1 before the chomp should like like above when printed out.

You are splitting on newlines. Why do you expect them to still be there?

a,b,c,d
e,f,g,h
i,j,k,l

@arr1 before the chomp should like like above when printed out.

Why would you expect that?

>perl -wMstrict -le
"my $s = qq{a,b,c,d\ne,f,g,h\ni,j,k,l};
 printf qq{$s};
 printf qq{\n};
 ;;
 my @ra = split /\n/, $s;
 printf qq{@ra};
 printf qq{\n};
 ;;
 chomp @ra;
 printf qq{@ra};
 printf qq{\n};
"
a,b,c,d
e,f,g,h
i,j,k,l
a,b,c,d e,f,g,h i,j,k,l
a,b,c,d e,f,g,h i,j,k,l
[download]

As others mentioned, the split will remove the newlines. However, if there is still unexplained weirdness you might want to check to see if there is an issue with how a newline is defined. Cross-platform differences can cause headaches. See Newlines: reading files that were created on other platforms and similar.

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]

chomp doesn't change the array because there is no newline in the array. split returns what's separated by the separator.

 +------------------> $arr1[0] = "aaa";
 |    +-------------> $arr1[1] = "bbb"; 
 |    |    +--------> $arr1[2] = "ccc";
 |    |    |   +----> empty field dropped
 |    |    |   |
---  ---  ---  -
aaa\nbbb\nccc\n
[download]