Anytime you see "see <Module::Name::Here>" you can do perldoc Module::Name::Here to see the documentation, provided the module is installed on your host.

In terms of finishing with the application, if you end up going with the IPC::Open[23] methodology you would do something ala

# assuming READ, and WRITE are the reader and writer FHs
# and $pid is the pid of the process spawned
close(READ);
close(WRITE);

waitpid $pid, 0;

# or if you used FileHandle objects or autovivified scalars
close($read);
close($write);

waitpid $pid, 0;
[download]

After rereading your post, I noticed I didn't answer the right question. How does the program presently know you are done writing? Is there some sentinel value? Do you pass a <CTRL> + d? You will simply do the same at the end of your write loop. Alternately if you don't have that functionality presently in the prog, you could add it and then make use of it :).

What they mean is to man IPC::Open2 or look at the IPC::Open2 library docs however you view library docs on your system. That whole "L<...>" is a way of doing a link to another data source in perl POD documentation... but it seems to be either broken or broken in your POD-viewer.

Oh, and as for signalling that you are done writing, etc... that's what they're talking about in the whole deadlock-prevention business. The issue is, you need to make it completely clear to each process which one is writing and which one is reading at any given time. If there is any ambiguity, and both process think that they should be reading or both think they should be writing... then you're deadlocked.

A simple means of avoiding this (if it fits your problem) is to provide "framing data" in your streams. This is sort of akin to saying "over" on a walky-talky. You mean "I'm done writing, it's your turn to write". The way you do that is you can isolate some string that should never appear in your data, and you send that string as a magical token over your stream as such a signal.

If there is no way to determine a token which should never appear in your data, then you would need to encapsulate your data somehow. A simple example is to pick some magical character... like let's say a newline character ("\n") and an escape character like a backslash. Then in the program writing the data, you turn all newlines into \n's and all \'s into \\'s, and in the reading program you do the opposite. Now the actual newline character won't appear anywhere in your data, and you can use it to "frame" your data.

# writer
$data =~ s/\\/\\\\/g;
$data =~ s/\n/\\/g;
print PIPE $data,"\n";

# reader
$/ = "\n";
$data = <PIPE>;
chomp $data;
$data =~ s/\\n/\n/g;
$data =~ s/\\\\/\\/g;
[download]

If you only have one batch of data to send to your child process, you can signal that you're done by just closing the write filehandle. The child process will see this as EOF in its STDIN, but will still be able to write to STDOUT just fine. Of course, once you've done this, you can't send any more data to the child process.

Here's a short example:

#!/usr/bin/perl -w

# This is t6

use strict;
use IPC::Open2;

open2(\*READ,\*WRITE,'/tmp/t6b')
  or die "Error running sort: $!\n";
print WRITE join("\n",5,2,8,7,9,1,3,6,4,0),"\n";
close(WRITE);
while (<READ>)
{
  print "$0 read $_";
}


#!/usr/bin/perl -w

# This is t6b

use strict;

use vars qw(@a);
while (<>)
{
  push(@a,$_);
}

# OK, now we've gotten EOF.
print sort @a;
[download]