Problème avec le handle de fichier canalisé en perl

Question

J'essaie d'exécuter bp_genbank2gff3.pl (paquet bioperl) à partir d'un autre script perl que obtient un genbank comme argument.

Cela ne fonctionne pas (pas de fichiers de sortie sont générés):

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

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

mais cela ne

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

Pourquoi?

Je pensais que close est censé bloquer jusqu'à ce que la commande se fait:

La fermeture d'un descripteur de fichier provoque canalisé le processus parent d'attendre l'enfant pour terminer ... (voir http://perldoc.perl.org/functions/open.html).

Modifier

J'ajouté ce dernier en ligne:

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

et dans les deux cas, l'impression est:

ret=, $?=13, $!= 

(ce qui signifie close a échoué dans les deux cas , à droite?)

Answer 1

$? = 13 signifie que votre processus fils a pris fin par un signal SIGPIPE. Votre programme externe (bp_genbank2gff3.pl) a essayé d'écrire une sortie vers un canal vers votre programme perl. Mais le programme perl a fermé son extrémité du canal afin que votre système d'exploitation envoie un SIGPIPE au programme externe.

Par sleep e pendant 3 secondes, vous laissez votre programme s'exécuter pendant 3 secondes avant que le système d'exploitation ne le tue, ce qui permet à votre programme de faire quelque chose. Notez que les tuyaux ont une capacité limitée, donc si votre script parent ne lit pas depuis le canal et si le programme externe écrit beaucoup sur la sortie standard, les opérations d'écriture du programme externe finissent par bloquer et vous ne pouvez pas vraiment obtenir 3 secondes d'effort de votre programme externe.

La solution de contournement consiste à lire la sortie du programme externe, même si vous allez simplement la jeter.

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

---

Mise à jour: Si vraiment vous ne se soucient pas de la sortie de la commande, vous pouvez éviter SIGPIPE problèmes en redirigeant la sortie vers /dev/null:

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

Bien sûr, si vous allez aller à tant de mal à ignorer la sortie, vous pouvez aussi bien utiliser system.

---

Informations complémentaires: Comme l'OP dit, la fermeture d'un descripteur de fichier fait que le parent canalisé d'attendre l'enfant à terminer (en utilisant waitpid ou quelque chose de similaire). Mais avant il commence à attendre, il ferme son extrémité du tuyau. Dans ce cas, cette extrémité est l'extrémité de lecture du canal vers lequel le processus enfant écrit sa sortie standard. La prochaine fois que l'enfant essaie d'écrire quelque chose sur la sortie standard, le système d'exploitation détecte que l'extrémité de lecture de ce canal est fermée et envoie un SIGPIPE au processus fils, le détruisant et laissant rapidement l'instruction close dans le parent.

Answer 2

Je ne suis pas sûr de ce que vous essayez de faire, mais system est probablement mieux dans ce cas ...