使用Perl调试器与像Devel :: REPL这样的真实REPL有什么缺点？

Question

我通常使用perl -de 42来获取交互式Perl shell。我看过Devel::REPL，我看过像http://www.xenoterracide.com/2010/07/making-repl-usable.html这样的博客，解释了如何使用插件增强Devel::REPL，但我还没有使用过。

将调试器用作交互式shell是否太糟糕了？为什么呢？

注意： 这个PerlMonks node中提到的缺点是用户的限制，而不是Perl调试器的限制。

我在哪里可以阅读有关Perl REPL的更多信息？

Devel :: REPL是否已成为众人瞩目的焦点？

更新 我接受了Pedro的答案，因为它回答了我提出的问题，但我仍然想知道何时以及为什么（如果有的话）使用Perl调试器作为交互式shell与Perl REPL实现之一相比是一个坏主意。您更喜欢哪种Perl REPL？

Answer 1

perl -d的一个缺点是词汇变量立即超出范围。例如：

DB<1> my $p = 123;

DB<2> print $p;

DB<3>

来自perldebug：

  

注意，所述eval受一个约束   隐含范围。结果任何新的   引入词汇变量或任何   修改后的捕获缓冲区内容   评估后丢失了。调试器是一个   学习Perl的好环境，但是如果   你交互式地试验使用   材料应该是相同的   范围，将其填入一个线性范围内，将其填入一行。

Answer 2

我倾向于使用

，而不是使用调试器并错过功能

perl -wnE'say eval()//$@'

我使用过Devel :: REPL并喜欢它，但从未习惯使用它。

使用调试器的一个优点是能够让$DB::single=1在给定点停止并单步执行。

Answer 3

两者都有不同的目标。调试器针对调试已经编写的Perl脚本/程序进行了优化。而REPL主要目标是提供快速语言反馈，并针对（开发人员）交互式输入进行了优化。

例如。如果我在Perl调试器中执行以下操作：

DB<1> for my $x (1..10) {

我收到Missing right curly or square bracket at (eval 5)...错误。

而Devel::REPL允许多行输入：

$ for my $x (1..3) {
> say $x;
> }
1
2
3

我完全推荐Devel::REPL并使用额外的插件，它成为一个方便的开发工具，可以在你的编辑器旁边运行。

/ I3az /