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 发行版附带的文档。
鉴于 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 也几乎一样好。
你的补丁可能会被退回，并要求你进行修改，或者要求你对你的修复提供更详细的解释。
以下是一些创建高质量补丁的提示
确保补丁没有反转（diff 的第一个参数通常是原始文件，第二个参数是修改后的文件）。在发送补丁之前，请确保你通过 git am 或 patch 程序应用补丁进行测试。尽量遵循你要修补的代码的相同风格。确保你的补丁确实有效（make test，如果要修补的内容包含在 Perl 的测试套件中）。
perlbug 提交感谢信吗？是的，你可以使用 -T 选项，或者将程序调用为 perlthanks 来实现。感谢信很好。它会让人们微笑。
请使你的问题标题信息丰富。“一个 bug” 不具有信息量。 “perl 崩溃” 也不具有信息量， “救命！！！” 也不具有信息量。这些都没有帮助。简洁地描述错误就可以了。
在你完成自己的工作后，请做好等待的准备，做好被告知错误在你自己的代码中，或者可能根本没有回复的准备。维护 Perl 的志愿者都很忙，所以如果你的问题是你自己代码中的明显错误，难以理解，或者与现有报告重复，你可能不会收到个人回复。
如果你的 bug 必须修复，请监控问题跟踪器（你将订阅你提交或评论的问题的通知）和 Perl 开发版本的提交日志，并用善意的话语或提供冰镇饮料来鼓励维护者。（请善待维护者。骚扰或辱骂他们可能会产生与你想要的结果相反的效果。）
如果发布了新版本的 Perl，而你的 bug 仍然存在，请随时在 https://github.com/Perl/perl5/issues 上更新你的 bug 的工单。
发送报告的地址，而不是保存到文件。
报告正文。如果命令行或使用 -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)
目前未知（猜猜看用来报告错误的是什么？）。