Your output will not be flushed until the program is finished, unless you forced it to be flushed in a way I demoed at the end of this post, or if your output is big enough to trigger the flush. Try the following code and observe, you will see that the output does not come out on the screen after 1 second, and the first batch of print only comes after about 20 seconds. That is the effect of buffering.

while (1) {
    print "0123456789" x 20;
    sleep(1);
}
[download]

With manual input, most likely you don't have enough input to trigger the print out. The flushing can also be triggered by the end of the program, but with a dead loop that's not happening either.

Even if there is any output, it will be quickly flushed out of the physical screen by all the error messages, and you are probably still not going to see the output.

But with this code you will see something printed every second:

while (1) {
    print "0123456789" x 20 . "\n";
    sleep(1);
}
[download]

This too:

$| ++;
while (1) {
    print "0123456789" x 20;
    sleep(1);
}
[download]

Or:

use IO::Handle;
STDOUT->autoflush();
while (1) {
    print "0123456789" x 20;
    sleep(1);
}
[download]

It works for me, input and output is:

$ perl bhcesl.pl
a       b       c
1       2       3
a-1b-2c
-3
------------------------------
[download]

I think that you may not be expecting to read STDIN from the command line. The wait for input could be mistaken for an infinite loop that wasn't printing anything.

The first two lines after "perl . . ." are the inputs, "a\tb\tc\n" and "1\t2\t3\n". Those newlines are seen in the output. chomp is the cure for that.

You are getting output, but it's being buffered. Add a "\n" to the print or add $|=1 somewhere before the loop to disable buffering.

By the way, you shouldn't use $a as a variable. It has a special meaning for certain function such as sort, and doing my $a screws things up.