You general approach is just fine. However, if you are always reading 2 lines at a time, why not just read them both in the while conditional? If there are an odd number of lines, below code will just throw away that last line that doesn't have a partner following it. The other question is what to do with blank lines at the end? Maybe somebody hit <cr> again a few times? Or mistake in cut-n-paste? I did something simple to allow for an undef resulting from split on "\n". Other implementations are of course possible, I don't know enough about your actual app.
I try to avoid stuff like $tmp[0] because you need a comment to describe what the heck the 0th field actually means! I used an array slice to move the indexing into the split so that I could assign this first column a scalar name. You should use terminology appropriate for your application. I didn't see the need for chomp, only to add a "\n" back in. The split will remove any \n if there is just one token on the line. Also, I personally wouldn't put multiple statements on the same line. Perl doesn't care, but people do.
I would do something different if this involved reading chunks of more than 2 lines. But this specific case, I find the below adequate.
use strict;
use warnings;
my $cnt=1;
while (defined (my $first = <DATA>) and defined (my $second = <DATA>)
+)
{
my $name1 = (split /\s+/, $first)[0] // last; # handle trailing
my $name2 = (split /\s+/, $second)[0] // last; # potential "\n" bl
+ank lines
print "$cnt\t$first";
if ($name1 ne $name2)
{
$cnt++;
}
print "$cnt\t$second";
}
=prints
1 one
1 one
1 two
1 two
1 three
1 three
1 three
2 four
note: same result with or without the trailing blank line
=cut
__DATA__
one
one
two
two
three
three
three
four
Odd line here followed by a blank line if you want
Update: Oh, I usually put the numbering on the left. I know how big that column is going to get. Done the other way around, a long token will screwup your nice printout. You didn't specify what is to happen with an odd number of line - it could be "silent ignore" approach above is not what you want - but I couldn't tell.