什么是首选的跨平台IPC Perl模块?

前端之家收集整理的这篇文章主要介绍了什么是首选的跨平台IPC Perl模块?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我想创建一个简单的IO对象,代表一个管道打开另一个程序,我可以定期写入另一个程序的STDIN作为我的应用程序运行.我想要它是防弹的(因为它捕获所有错误)和跨平台.我可以找到最好的选择是:

打开

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

优点:

>跨平台
>简单

缺点

> No $SIG {PIPE}从管道程序中捕获错误
>其他错误是否被捕获?

IO ::管

sub io_read {
    IO::Pipe->reader(@_);
}

优点:

>简单
>返回OO接口的IO :: Handle对象
>由Perl核心支持.

缺点

>仍然没有$SIG {PIPE}从管道程序中捕获错误
> Win32不支持(或至少,its tests被跳过)

IPC ::运行

在IPC :: Run中没有写入文件句柄的接口,只附加到标量.这似乎很奇怪

IPC :: RUN3

这里也没有文件句柄界面.我可以使用一个代码引用,它将被重复地调用到子节点,但是查看源代码,看起来它实际写入一个临时文件,然后打开它并将其内容截取到pipe’d命令的STDIN.世界卫生大会?

IPC :: Cmd的

仍然没有文件句柄界面.

我在这里缺少什么?似乎这应该是一个解决的问题,我很震惊,它不是. IO ::管道最接近我想要的,但缺少$SIG {PIPE}错误处理和对Windows的缺乏支持令人不安. JDWIM的管道模块在哪里?

解决方法

感谢@ikegami的指导,我发现在Perl中交互式阅读和写入另一个进程的最佳选择是IPC :: Run.但是,它要求您正在读取和写入的程序在写入其STDOUT(例如提示)时具有已知的输出.这是一个执行bash的例子,它运行ls -l,然后打印输出
use v5.14;
use IPC::Run qw(start timeout new_appender new_chunker);

my @command = qw(bash);

# Connect to the other program.
my ($in,@out);
my $ipc = start \@command,'<' => new_appender("echo __END__\n"),\$in,'>' => new_chunker,sub { push @out,@_ },timeout(10) or die "Error: $?\n";

# Send it a command and wait until it has received it.
$in .= "ls -l\n";
$ipc->pump while length $in;

# Wait until our end-of-output string appears.
$ipc->pump until @out && @out[-1] =~ /__END__\n/m;

pop @out;
say @out;

因为它是作为一个IPC运行的(我假设),当它完成写入其STDOUT时,bash不会发出提示.所以我使用new_appender()函数让它发出一些我可以匹配来找到输出的结尾(通过调用echo __END__).在调用new_chunker之后,我也使用了一个匿名子例程来将输出收集到一个数组中,而不是一个标量(只要传递一个标量的引用到’>’,如果你愿意的话).

所以这是有效的,但它吸引了很多原因,在我看来:

>没有一般的有用的方法来知道IPC控制的程序已经完成打印到其STDOUT.相反,您必须在其输出上使用正则表达式来搜索通常意味着完成的字符串.
>如果它不发出一个,你必须把它引入一个(正如我在这里做的 – 上帝禁止我应该有一个名为__END__的文件).如果我正在控制一个数据库客户端,我可能需要发送一些像“这里的IM OUTTA”这样的东西.不同的应用程序将需要不同的new_appender黑客.
>对魔术$in和$out标量的写作感觉很奇怪,并且在一个距离的行动.我不喜欢
>如果标题文件句柄,则不能对标量进行线性处理.因此它们效率较低.
>使用new_chunker获取线性输出的能力是很好的,如果还是有点奇怪.尽管如此,通过IPC :: Run可以高效地缓存来从程序中读取输出的效率.

我现在意识到,虽然IPC :: Run的接口可能会更好一些,但总体来说,IPC模型的缺点尤其在于处理这个问题.没有一般有用的IPC界面,因为人们必须知道要运行的特定程序的具体细节.这可以,如果您确切知道它将如何对输入做出反应,并且可以可靠地识别何时完成发布输出,并且不需要担心跨平台兼容性.但是,这远远不足以满足我对通用有用的方式与CPAN模块中的各种数据库命令行客户端进行交互的需求,该模块可以分发给整个操作系统.

最后,由于a blog post评论中的包装建议,我决定放弃使用IPC控制这些客户端,而是使用the DBI.它提供了一个优秀的API,强大,稳定和成熟,并且没有任何IPC的缺点.

我对那些跟随我的人的建议是:

>如果您只需要执行另一个程序并等待完成,或者在完成运行时收集其输出,请使用IPC::System::Simple.否则,如果您需要做的是与其他内容进行交互式接口,请尽可能使用API .如果不可能的话,请使用像IPC::Run这样的东西,尽量做到这一点 – 并准备好放弃你的时间让它“正确”.

猜你在找的Perl相关文章