Question

I am trying to run bp_genbank2gff3.pl (bioperl package) from another perl script that
gets a genbank as its argument.

This does not work (no output files are generated):

   my $command = "bp_genbank2gff3.pl -y -o /tmp $ARGV[0]";

   open( my $command_out, "-|", $command );
   close $command_out;

but this does

   open( my $command_out, "-|", $command );
   sleep 3; # why do I need to sleep?
   close $command_out;

Why?

I thought that close is supposed to block until the command is done:

Closing any piped filehandle causes
the parent process to wait for the
child to finish…
(see http://perldoc.perl.org/functions/open.html).

Edit

I added this as last line:

say "ret=$ret, \$?=$?, \$!=$!";

and in both cases the printout is:

ret=, $?=13, $!=

(which means close failed in both cases, right?)

Answer 1

$? = 13 means your child process was terminated by a SIGPIPE signal. Your external program (bp_genbank2gff3.pl) tried to write some output to a pipe to your perl program. But the perl program closed its end of the pipe so your OS sent a SIGPIPE to the external program.

By sleeping for 3 seconds, you are letting your program run for 3 seconds before the OS kills it, so this will let your program get something done. Note that pipes have a limited capacity, though, so if your parent perl script is not reading from the pipe and if the external program is writing a lot to standard output, the external program’s write operations will eventually block and you may not really get 3 seconds of effort from your external program.

The workaround is to read the output from the external program, even if you are just going to throw it away.

open( my $command_out, "-|", $command );
my @ignore_me = <$command_out>;
close $command_out;

---

Update: If you really don’t care about the command’s output, you can avoid SIGPIPE issues by redirecting the output to /dev/null:

open my $command_out, "-|", "$command > /dev/null";
close $command_out;     # succeeds, no SIGPIPE

Of course if you are going to go to that much trouble to ignore the output, you might as well just use system.

---

Additional info: As the OP says, closing a piped filehandle causes the parent to wait for the child to finish (by using waitpid or something similar). But before it starts waiting, it closes its end of the pipe. In this case, that end is the read end of the pipe that the child process is writing its standard output to. The next time the child tries to write something to standard output, the OS detects that the read end of that pipe is closed and sends a SIGPIPE to the child process, killing it and quickly letting the close statement in the parent finish.