while (<F0>)
[download]

On the other hand,

while (<F1> && ($line_stop++ < $line_no))
[download]

See I/O Operators for details.

Additionally, from open, use the three arg open:

open(my $fh, "<", "input.txt")
    or die "Can't open < input.txt: $!";
[download]

Also: http://modernperlbooks.com/mt/2010/04/three-arg-open-migrating-to-modern-perl.html.

And I don't think it's been mentioned yet but nesting your while loops reading like that doesn't make much since sense. You're going to read the first line from FO, then you're going to read all the lines from F1 (modulo the problems already mentioned there). The next time through it would try and read the next line from F0 but when it tried to read from F1 again that's going to still be at the end of the file and not do anything useful.

That being said this whole thing's a mess between the formatting and the logic; I don't have the time (nor inclination, honestly) to untangle it. You should stop and take a step back and think what you're doing and change your approach. But as I said, I can't make heads nor tails of what you're attempting to do so I don't really have any suggestion what you should be doing (like what data structure you'd want to parse the shorter/smaller file into to consult against as you read through the larger one).

Edit: ENOCAFFEINE. A word.

while (<F1> && ($line_stop++ < $line_no)) { 
   while (s/^[\ \t]//g) {} };
[download]

Your code is so confusing, I have no idea what it is really supposed to do. But I took a wild ass guess based upon just looking at the input files. Code below which uses a tricky feature of opening a Perl variable like an input file so that I can show everything as a single runnable Perl program.

Maybe back up and explain what you are trying to do?

use strict;
use warnings;

my $IP_file = << 'END';
1.0.129.197
1.0.131.49
1.0.131.74
1.0.138.143
1.0.138.154
1.0.139.72
END

my $Port_file = << 'END';
3        PORT    state    protocol
3        80/tcp   closed http
3        443/tcp  closed https
3        8080/tcp open   http-proxy
5        80/tcp   open     http
5        443/tcp  filtered https
5        8080/tcp filtered http-proxy
END

my $output_file;

open my $IP,   "<", \$IP_file      or die "unable to open IP file for 
+reading $!"; 
open my $PORT, "<", \$Port_file    or die "unable to open port file fo
+r reading $!"; 
open my $OUT,  ">", \$output_file  or die "unable to open output file 
+for writing $!";

<$PORT>;  # throw away first line ion port file

while (defined (my $ip_line =<$IP>) and defined (my $port_line = <$POR
+T>))
{
   chomp $ip_line;
   $port_line =~ s/^\d+\s+/$ip_line /;
   print "$port_line";
}

__END__
Prints:
1.0.129.197 80/tcp   closed http
1.0.131.49 443/tcp  closed https
1.0.131.74 8080/tcp open   http-proxy
1.0.138.143 80/tcp   open     http
1.0.138.154 443/tcp  filtered https
1.0.139.72 8080/tcp filtered http-proxy
[download]

The reads a line from F1 and puts it into $_

wrong

You are correct. This is an artifact of having the logical statement in the conditional. while (<FH>){} does assign the line to $_. However, while (<FH> and some condition){} doesn't assign the read line to $_ only the "truthiness" of whether a line was actually read or not is used (the line itself is thrown away). Ok, we have found yet another reason why this odd looking while statement won't work. while (defined (my $line =<FH>) and some condition){} is perhaps better. It is possible to assign to $_ (left hand side), but I seldom do that. This whole idea of an "and" or "&&" statement in the while condition looks dubious to me.

Just to throw some TMTOWTDI in .. you could also use Tie::File to read from the files; that way, you could read through the inner file without having to rewind. Then again, it also looks like you could just load the files into data structures once, then figure stuff out by looking at the structures.

First of all, you don't want Tie::File. You never want Tie::File

What happened to strict and warnings in your code? Also, i recommend that you use Carp. The "English" module also makes your code clearer. Avoid the implicit variable $_ - it is (in my opinion) the spawn of evil and should be avoided at all costs to make code easier to read.

#!/usr/bin/env perl

use strict;
use warnings;
use Carp;
use English;
[download]

open(F0, $ARGV[0]); open(F1, $ARGV1); open(F2, ">$ARGV2");

Urgh, there are so many things wrong with that, it gives me an instant headache. First of all, do not use plain file handles, use variables. Use three-argument open(). Check the return value of open(). Use multiple lines. Put the ARGV stuff into named variables to make the code clearer. Use proper variable names for the filehandle, so you know later in the code which handle does what.

my ($ipfname, $portfname, $resultfname) = @ARGV;

open(my $ipfh, '<', $ipfname) or croak($ERRNO);
open(my $portfh, '<', $portfname) or croak($ERRNO);
open(my $resultfh, '>', $resultfname) or croak($ERRNO);
[download]

I can't really make out what the rest of your code is trying to do. I'll suggest you implement the recommendations by me and the others who have already replied to your question and see if that helps. You can always come back with a new question, but please do at least the following:

1. Explain what your code is trying to do. Adding an example output (can be edited by hand) is very helpful.
2. Implement our recommendations as far as possible. "use strict" and "use warnings" are pretty much a requirement these days.
3. Make your code more readable. One command per line, proper indentation.
4. Add comments. Especially comment on the regular expressions. Yes, we can "decode" them, but it's easier if you already tell us what they are supposed to do. Makes the code easier to understand and allows us to check if the regex actually does what you think it should do.
5. Use variables with names that hint at their intended purpose.
6. Check the return value of open().
7. Show us your error messages (if any).

Most of us have limited time to understand questions and come up with good answers. The best way for us to help you is for you to help us in providing a good question that is easy to read, easy to understand and has readable example code (and example data, if applicable).

I can only speak for this from my own point of view, but say there are three new SoPW questions. Two of them are easy to understand and one would take an hour just to understand what the example code might try to do. I'm not talking about how complicated itis to come up with a solution, just how hard it is to even understand what the problem is. In this case i will probably work on the two easy questions and ignore the confusing one.