perlbug - 如何提交 Perl 的错误报告
perlbug
perlbug [ -v ] [ -a 地址 ] [ -s 主题 ] [ -b 正文 | -f 输入文件 ] [ -F 输出文件 ] [ -r 回复地址 ] [ -e 编辑器 ] [ -c 管理员地址 | -C ] [ -S ] [ -t ] [ -d ] [ -h ] [ -T ]
perlbug [ -v ] [ -r 回复地址 ] [ -ok | -okay | -nok | -nokay ]
perlthanks
该程序旨在帮助您生成有关 perl5 及其附带模块的错误报告（以及感谢信）。
在大多数情况下，您只需从命令行以交互方式运行它，无需任何特殊参数，并按照提示操作即可。
如果您在非标准端口（不是标准发行版的一部分）、二进制发行版或非核心模块（如 Tk、DBI 等）中发现了错误，请参阅该发行版附带的文档以确定报告错误的正确位置。
错误报告应提交到 GitHub 问题跟踪器 https://github.com/Perl/perl5/issues。[email protected] 地址不再自动打开工单。您可以使用此工具撰写您的报告并将其保存到文件，然后将其提交到问题跟踪器。
在极端情况下，perlbug 可能无法在您的系统上正常工作以指导您撰写错误报告。在这些情况下，您可能可以使用 perlbug -d 或 perl -V 获取系统配置信息以包含在您的问题报告中。
在报告错误时，请查看以下清单
在命令行中键入 perl -v 以找出答案。
查看 https://www.perl5.cn/ 以找出答案。如果您没有使用最新的发布版本，请尝试在最新的稳定版本上复制您的错误。
请注意，有关旧版本 Perl 中错误的报告，尤其是那些表明您尚未在当前稳定版本 Perl 上进行测试的报告，可能会比有关当前版本中错误的报告获得来自构建和维护 Perl 的志愿者的更少关注。
我们收到的许多错误报告最终被证明是 Perl 中的已记录功能。请确保您遇到的问题不是故意的，方法是浏览 Perl 发行版附带的文档。
鉴于 Perl 文档的庞大数量，这并非易事，但如果您能指出文档中表明您所见行为是错误的，您的问题可能会得到更多关注。您可能需要从perldoc perltrap 开始，以了解新（和经验丰富的）Perl 程序员遇到的常见陷阱。
如果您不确定遇到的错误消息的含义，请使用perldoc perldiag 进行解释。如果该消息不在 perldiag 中，它可能不是由 Perl 生成的。您可能需要参考您的操作系统文档。
如果您使用的是非 UNIX 平台，请使用perldoc perlport，因为某些功能可能未实现或工作方式不同。
您可能可以使用 Perl 调试器找出问题所在。有关如何使用调试器的信息，请使用perldoc perldebug。
越容易重现您的错误，它就越有可能被修复 - 如果没有人能够复制您的问题，它可能不会被解决。
一个好的测试用例具有以下大多数属性：简短、简单的代码；对外部命令、模块或库的依赖性较少；没有平台相关的代码（除非它是平台特定的错误）；清晰、简单的文档。
一个好的测试用例几乎总是可以很好地包含在 Perl 的测试套件中。如果您有时间，请考虑编写您的测试用例，以便它可以轻松地包含在标准测试套件中。
请务必包含确切的错误消息（如果有）。“Perl 出错”不是确切的错误消息。
如果您得到核心转储（或等效项），您可以使用调试器（dbx、gdb 等）生成堆栈跟踪以包含在错误报告中。
注意：除非您的 Perl 已使用调试信息（通常为-g）编译，否则堆栈跟踪可能难以使用，因为它很可能只包含函数名称，而不包含其参数。如果可能，请使用调试信息重新编译您的 Perl，并重现崩溃和堆栈跟踪。
越容易理解可重现的错误，它就越有可能被修复。您提供的任何关于问题的见解都将非常有帮助。换句话说，尝试分析问题（尽你所能）并报告你的发现。
如果是这样，那真是个好消息；带有补丁的错误报告比没有补丁的错误报告更有可能得到更多的关注和兴趣。请通过 GitHub Pull Request 工作流程提交您的补丁，如 perldoc perlhack 中所述。您也可以将补丁发送到 [email protected]。发送补丁时，如果可能，请使用 git format-patch 创建它，尽管使用 diff -pu 创建的统一差异几乎一样好。
您的补丁可能会被退回，要求您进行更改，或要求您提供有关修复的更详细的解释。
以下是一些创建高质量补丁的提示
确保补丁没有反转（diff 的第一个参数通常是原始文件，第二个参数是您更改的文件）。确保您通过使用 git am 或 patch 程序应用补丁来测试您的补丁，然后再发送它。尝试遵循您要修补的代码的相同风格。确保您的补丁确实有效（make test，如果您要修补的内容包含在 Perl 的测试套件中）。
perlbug 提交感谢信吗？是的，您可以通过使用 -T 选项或将程序调用为 perlthanks 来做到这一点。感谢信很好。它会让人们微笑。
请使您的问题标题信息丰富。“一个错误”没有信息量。“perl 崩溃”也不行，也不要写“救命！！！”。这些都没有帮助。简要描述错误就可以了。
完成了您的工作后，请准备好等待，被告知错误在您的代码中，或者可能根本没有收到回复。维护 Perl 的志愿者都很忙，所以如果您的问题是您自己代码中的明显错误，难以理解或与现有报告重复，您可能不会收到个人回复。
如果修复您的错误对您很重要，请监控问题跟踪器（您将订阅您提交或评论的问题的通知）和 Perl 开发版本的提交日志，并用友好的话语或提供冰镇饮料来鼓励维护者。（请善待维护者。骚扰或辱骂他们可能会产生与您想要的效果相反的效果。）
如果您在发布新版本的 Perl 后，您的错误仍然存在，请随时在 https://github.com/Perl/perl5/issues 上更新您的错误票证。
发送报告的地址，而不是保存到文件。
报告正文。如果命令行或使用 -f 的文件未包含报告正文，您将有机会编辑报告。
通过邮件发送报告时，不要将副本发送给管理员。
通过邮件发送报告时，发送报告副本的地址。默认为本地 perl 管理员的地址（在构建 perl 时记录）。
数据模式（如果您重定向或管道输出，则为默认模式）。这将打印您的配置数据，而不会保存或发送任何内容。您可以将它与 -v 一起使用以获取更完整的数据。
要使用的编辑器。
包含报告正文的文件。使用此选项快速发送准备好的报告。
输出结果的文件。默认为 perlbug.rep。
打印选项的简要摘要。
向 perl 维护者报告此系统上的成功构建。强制使用 -S 和 -C。强制并提供 -s 和 -b 的值。只有在无法猜测返回地址时才会提示输入返回地址（用于 make）。遵守使用 -r 指定的返回地址。您可以将它与 -v 一起使用以获取更完整的数据。只有当此系统年龄小于 60 天时才会生成报告。
与 -ok 相同，但它会报告更旧的系统。
报告此系统上的构建失败。强制使用 **-C**。强制并提供 **-s** 的值，然后要求您编辑报告并说明问题所在。或者，可以使用 **-f** 提供准备好的报告。仅当无法猜测返回地址（用于 **make**）时才会提示输入返回地址。遵守使用 **-r** 指定的返回地址。您可以将其与 **-v** 一起使用以获取更完整的数据。仅当此系统的使用时间少于 60 天时才会生成报告。
与 **-nok** 相同，但它会报告更旧的系统。
要包含在报告中的一个或多个补丁文件或其他文本附件的名称。多个文件必须用逗号分隔。
您的返回地址。如果您不使用此选项，程序会要求您确认其默认值。
保存或发送报告，无需确认。
要包含在报告中的主题。如果您没有在命令行中提供主题，系统会提示您输入。
测试模式。使从管道或文件命令 perlbug 成为可能，用于测试目的。
发送感谢信而不是错误报告。
在报告中包含详细的配置数据。
Kenneth Albanowski (<[email protected]>)，后来由 Gurusamy Sarathy (<[email protected]>)、Tom Christiansen (<[email protected]>)、Nathan Torkington (<[email protected]>)、Charles F. Randall (<[email protected]>)、Mike Guy (<[email protected]>)、Dominic Dunlop (<[email protected]>)、Hugo van der Sanden (<[email protected]>)、Jarkko Hietaniemi (<[email protected]>)、Chris Nandor (<[email protected]>)、Jon Orwant (<[email protected]>)、Richard Foley (<[email protected]>)、Jesse Vincent (<[email protected]>) 和 Craig A. Berry (<[email protected]>) 共同撰写。
perl(1)、perldebug(1)、perldiag(1)、perlport(1)、perltrap(1)、diff(1)、patch(1)、dbx(1)、gdb(1)
尚无已知错误（猜猜看用来报告错误的是什么？）。