If you are absolutely sure that they are text files, ... something like the following could be used to normalize everything to match your current system's line endings.

Assume the content of the file is in $file:

Now when you write the string to disk, the line endings will be consistent.

It's important to do the alternation in the correct order, otherwise you can get a surprising result. If you don't have to worry about old Macs, you can get away with:

Make certain you don;t do this to non-text files, the results are not recoverable.

If you don't have to worry about old Macs, you don't have to worry about running on old Macs, so you can get away with

s/\r?\n/\n/g
[download]

or just

s/\r(?=\n)//g
[download]

I remember a thread here recently pointing out that \n is not guaranteed to be a line feed, and that the suggested approach approach was to use \x0a and \x0d because you can be sure of their meanings.

I vaguely remember having that problem way back when I was a C programmer.

G. Wade

Since we're using CGI.pm's upload function, $file is the file name on the client computer (in a scalar context) or a file-handle, but not the contents of the file itself. As such, $file =~ s/(\x0d?\x0a|\x0d)/\n/smg; is performing the substitution on the file name, not the contents of the file. But, its a good idea.

Manually setting $/ works but how do I detect what the line-ending should be so I can set $/ programmatically? perlvar is very explicit about it being a string, not a regex, so that's not an option. And the line-ending can be different for each of the three files being uploaded, even within a single CGI upload, so I cannot even do something based on the browser User-Agent.

As I said, if we assumed the content of the file was in $file we could use that expression. If you want the content elsewhere, you can change the expression.

If you are looking at determining the line ending while reading the data from the socket, you might want to look at the user agent identification in the HTTP_USER_AGENT environment variable. You should be able to determine the OS from there.

G. Wade

foreach my $line (<$filehandle>)
[download]

while (my $line = <$filehandle>)
[download]

key1{tab}value1{\cM}key2{tab}value2{\cM}key3{tab}value3{\cM}key4{tab}value4

#!/usr/bin/perl -T

use CGI;
my $cgi = new CGI;

my $file = $cgi->upload('file');

print "Content-type: text/plain\n\n";

$file =~ s/(\x0d?\x0a|\x0d)/\n/smg;
while (my $line = <$file>)
{ 
  chop $line;
  ($key, $value) = split(/\t/,$line);
  print "key: $key\nvalue: $value\n";
}

key: key1
value: value1{\cM}key2

Well, if you know the length of the # of pairs then I'm assuming you could figure out the easy answer, but I'm guessing you're looking at a dynamic field length.

For something dynamic... i would look at the dos2unix docs to see what the tool is removing to make it unix compat (guessing u've been there though).

Outside of all that, I would be inclined to try something like:

while (my $line = <INFILE>) {
    $line =~ s/\n$//;
    while ($line =~ s/(\w+)\/(\w+)//) { #the {\cM} should create a wor
+d boundry since it's not alpha numeric
        print "key: $1\nvalue: $2\n";
    }
}
[download]

if you're looking at something where the line feeds are not showing up at all (so that the whole file is read in as one line....), I'm not 100% sure. I'll think about it, but have not run accross that particular scenario yet.

Its one long line of input, at least with this particular test file. And, your guess is correct... varied-length data so we can't just count characters or anything like that.