If you're still confused after checking the perldoc pages Abigail-II suggests, here's a quick background on what exactly pipes do in a Unix environment. Unix has 3 standard file handles that every process interacts with: STDIN, STDOUT, STDERR (standard in, out and error, respectively). Usually when you run a command from your shell on a Unix box, your keyboard input is available to the process as STDIN, and your display becomes STDOUT and STDERR. The main functional output of the program will go to STDOUT, while error messages and debugging are usually written to STDERR. Implemented in perl, these are the standard <STDIN>, <STDOUT> and <STDERR> handles that require no calls to the open() function.

#...
print "Tell me your name.\n" # Implied "print <STDOUT> ..."
chomp(my $name = <STDIN>);
unless ($name) {
   print STDERR "User did not provide a name...\n";
}
#...
[download]

Piping is a method of handing over these filehandles to other processes, allowing one command to work with the output of another. Unix systems tend to implement features with tiny commands that do one thing. This allows the user to string several commands together to accomplish a goal.

$ ps auxw | grep perl | awk ' {print $2} ' | mail -s "Perl PIDs" kgale
[download]

This would start the following commands: ps, grep, awk, mail. The STDOUT belonging to ps would become STDIN on grep, and so on. Eventually, a message would be mailed to the user "kgale" with only the second column (process ID) of lines containing the word "perl" from the output of "ps" (system process list). Since a standard pipe only redirects STDIN and STDOUT, STDERR would continue to be sent to the user's console. For more information on how piping is implemented on your particular shell, check your shell's man page:

$ man `basename $SHELL`
[download]