Probably the best approach would be to do a proper system-to-system transfer in the first place. (Update: On second thought, see below for probable BP.) E.g., the ftp utility common to most (all?) OSen has an ascii mode (automatic line-end translation) as well as a binary (don't touch nuthin') mode.

Otherwise, doing something like
    $line =~ s{ [\x0d\x0a]+ \z }{}xms;
to each and every line would do the trick to eliminate any possible combination of  \x0d and  \x0a characters from the end of the line. Other regexes can handle more particular combinations of line-enders.

Ugh. I prefer transfers to remain as dumb as possible, as usually somebody switches to compressed files instead of text files somewhere down the road. Also, finding out whether two data deliveries are the same becomes really hard if their checksums and filesizes don't match at either end.

So I'm firmly in the latter camp of doing the conversion in Perl instead of doing the conversion at transfer time.

Updated

I was wrong. Somehow, I remembered it working differently.

But { local $/ = ''; chomp($x); } seems to work. Needs more testing and I'm not sure there would still be a performance benefit.

Try chomp; chomp; instead of chop; chop;

chomp is conditional. Being built in, I would expect it to be more efficient than a regex.

That's wrong in this specific case. Here, you have a Windows file with "\r\n" line ends. Under Unix, the chomp command will remove only the "\n" part, but not the "\r". Using chomp a second time will not remove the "\r" under Unix. So the printing goes back to line start and the three !!! overwrite the beginning of the line.

The best solution here is to remove the "\r":

chomp $line;
$line =~ s/\r//g;
[download]

or

$line =~ s/[\r\n]//g;
[download]