I’m running Windows XP, Eclipse 3.2 with EPIC and Cygwin for my Perl interpreter, and I get an unexpected result.
FYI… When I run it on my Ubuntu distribution (VMware, same pc) I get the expected results. Why?
############ CODE: #############
use warnings;
use strict;
my $test = "test";
my $input = <STDIN>;
print length $test, " ", length $input, "\n";
chomp $input;
print "|$test| |$input| \n"; #The bars indicate white space, new line, etc...
print length $test, " ", length $input, "\n";
if ($test eq $input) {
print "TIME TO QUIT";
}
Results on Windows XP:
test <-- My input
4 6 <-- Lengths printed before chomp
|test| |test <-- Print the variables after chomp
| <-- There is still a new line there
4 5 <-- Lengths after the initial chomp
Based on the lengths, I’d say you’re getting the input string as:
where
<cr>and<lf>are ASCII codes 0x13 and 0x10 respectively.When you chomp it, it removes the
<lf>but leaves the<cr>there.It’s almost certainly an interaction issue between Eclipse, Cygwin and Windows, disagreeing on what the end-of-line character sequence should be. I couldn’t replicate your problem with just Perl/Cygwin or Perl/Windows but this command gives similar results (in Cygwin):
(
qq.plis your script and"^M"is the actual CTRL-M). Here’s the output in text form:and octal dump:
So I’d say that your input is putting on both
<cr>and<lf>, and the print is translating<cr>to<lf>(or just doing the same thing for both of them).If you need a workaround for your environment, you can replace your
chompline with:as in:
which works on Cygwin for the test data I used (check it for your own situation, of course), but you may find you can solve it better by using tools that all agree on the line end sequence (eg, Perl for Windows rather than the Cygwin one may do the trick for you).