Most likely a difference in line end characters. "DOS" uses crlf where *nix uses lf and Mac uses cr.

chomp (by default) removes the line end sequence used by the host OS so if you are running *nix and you have a file containing crlf line ends then you will get the cr left at the end of the line causing the password match to fail.

I'm interested in the explanation by GrandFather:

chomp (by default) removes the line end sequence used by the host OS so if you are running *nix and you have a file containing crlf line ends then you will get the cr left at the end of the line causing the password match to fail.

This being the case, is there a simple means to convert such DOS formated files to a 'nix format? My success in doing this, so far, has been to select, copy and paste the text to an empty 'nix file.

Thanks for the several helpful comments!

The easiest way to convert a DOS file to *nix line endings is (from the command line):

  dos2unix filename
[download]

Clint

The easiest way to cope with unpredictable line-termination patterns in data files is to avoid using "chomp", and instead do this:

my $infile = "some_indeterminate_kindof.txt";
open( IN, "<", $infile ) or die "$infile: $!\n";

my @raw_lines = <IN>;
close IN;

s/[\r\n]+$// for ( @raw_lines );  # "chomp" for both dos and unix

my @text_lines = map { split /\r+/ } @raw_lines;  # for (old or oddbal
+l) mac files
[download]

Regarding that comment about "old or oddball" mac files: since macosx is built atop BSD UNIX, it's entirely likely (and normal) for text files on current macs to use LF rather than CR line termination (i.e. when they've been created by perl or unix shell operations). But there are some "legacy style" operations and tools still operating in macosx that may create CR-terminated text files as well.

That snippet should also work as intended in case you happen to get "hybrid" input (e.g. in cases where a single text stream is really a "raw" concatenation of files with different line-termination patterns).