Was ist das bevorzugte plattformübergreifende IPC-Perl-Modul?

Ich möchte ein einfaches E / A-Objekt erstellen, das eine Pipe darstellt, die für ein anderes Programm geöffnet wurde, damit ich regelmäßig in die STDIN eines anderen Programms schreiben kann, während meine App ausgeführt wird. Ich möchte, dass es kugelsicher (da es alle Fehler auffängt) und plattformübergreifend ist. Die besten Optionen, die ich finden kann, sind:

open
<code>sub io_read {
    local $SIG{__WARN__} = sub { }; # Silence warning.
    open my $pipe, '|-', @_ or die "Cannot exec $_[0]: $!\n";
    return $pipe;
}
</code>

Vorteile:

PlattformübergreifendEinfach

Nachteile

Nein$SIG{PIPE} Fehler aus dem Pipe-Programm abfangenWerden andere Fehler abgefangen?IO :: Pipe
<code>sub io_read {
    IO::Pipe->reader(@_);
}
</code>

Vorteile:

EinfachGibt ein IO :: Handle-Objekt für die OO-Schnittstelle zurückUnterstützt vom Perl-Core.

Nachteile

Immer noch nein$SIG{PIPE} Fehler aus dem Pipe-Programm abfangenNicht unterstützt auf Win32 (oder zumindestseine Tests übersprungen werden)IPC :: Run

Es gibt keine Schnittstelle zum Schreiben in ein Datei-Handle in IPC :: Run, sondern nur zum Anhängen an einen Skalar. Das scheint ... seltsam.

IPC :: Run3

Auch hier gibt es keine Schnittstelle für Dateihandles. Ich könnte einen Codeverweis verwenden, der wiederholt aufgerufen wird, um das untergeordnete Element zu spoolen, aber beim Betrachten des Quellcodes scheint es, dass es tatsächlich in eine temporäre Datei schreibt und diese dann öffnet und spooltes ist Inhalt zu den Pipe'd-BefehlenSTDIN. Was?

IPC :: Cmd

Immer noch keine Datei-Handle-Schnittstelle.

Was vermisse ich hier? Es scheint, als ob dies ein gelöstes Problem sein sollte, und ich bin irgendwie fassungslos, dass es nicht so ist. IO :: Pipe kommt dem am nächsten, was ich will, aber der Mangel an$SIG{PIPE} Die Fehlerbehandlung und die mangelnde Unterstützung für Windows ist bedrückend. Wo ist das Rohrleitungsmodul, das JDWIM verwendet?

Antworten auf die Frage(2)

Ihre Antwort auf die Frage