perlbug - 如何提交 Perl 錯誤報告
perlbug
perlbug [ -v ] [ -a address ] [ -s subject ] [ -b body | -f inputfile ] [ -F outputfile ] [ -r returnaddress ] [ -e editor ] [ -c adminaddress | -C ] [ -S ] [ -t ] [ -d ] [ -h ] [ -T ]
perlbug [ -v ] [ -r returnaddress ] [ -ok | -okay | -nok | -nokay ]
perlthanks
此程式旨在協助您產生關於 perl5 及其隨附模組的錯誤報告（和感謝函）。
在多數情況下，您只要從命令列以互動方式執行它，不需任何特殊參數，並遵循提示即可。
如果您發現非標準埠（非標準發行版的一部分）、二進位發行版或非核心模組（例如 Tk、DBI 等）的錯誤，請參閱該發行版附帶的文件，以確定正確的錯誤報告位置。
錯誤報告應提交至 https://github.com/Perl/perl5/issues 上的 GitHub 問題追蹤器。perlbug@perl.org 位址不再自動開啟票證。您可以使用此工具撰寫報告並儲存至檔案，然後提交至問題追蹤器。
在極端情況下，perlbug 可能無法在您的系統上順利運作，無法引導您撰寫錯誤報告。在這些情況下，您可能可以使用 perlbug -d 或 perl -V 取得系統組態資訊，以納入您的問題報告中。
報告錯誤時，請執行此檢查清單
在命令列中輸入 perl -v 以找出。
查看 http://www.perl.org/ 以找出。如果您未使用最新發布版本，請嘗試在最新的穩定版本上複製您的錯誤。
請注意，關於舊版 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，並重現崩潰和堆疊追蹤。
一個可重現的錯誤越容易理解，就越有可能被修復。你提供的任何問題見解都將有很大的幫助。換句話說，請嘗試分析問題（在你能力範圍內），並報告你的發現。
如果是這樣，那就太好了；包含修補程式的錯誤報告可能會比沒有修補程式的報告得到更多的關注和興趣。請透過 perldoc perlhack中所述的 GitHub Pull Request 工作流程提交你的修補程式。你也可以將修補程式寄送至 perl5-porters@perl.org。寄送修補程式時，請盡可能使用 git format-patch 建立，儘管使用 diff -pu 建立的統一 diff 也可以。
你的修補程式可能會被退回，要求變更，或要求提供更詳細的修復說明。
以下是建立高品質修補程式的幾個提示
確保修補程式未反轉（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 (<kjahds@kjahds.com>)，隨後由 Gurusamy Sarathy (<gsar@activestate.com>)、Tom Christiansen (<tchrist@perl.com>)、Nathan Torkington (<gnat@frii.com>)、Charles F. Randall (<cfr@pobox.com>)、Mike Guy (<mjtg@cam.ac.uk>)、Dominic Dunlop (<domo@computer.org>)、Hugo van der Sanden (<hv@crypt.org>)、Jarkko Hietaniemi (<jhi@iki.fi>)、Chris Nandor (<pudge@pobox.com>)、Jon Orwant (<orwant@media.mit.edu>)、Richard Foley (<richard.foley@rfi.net>)、Jesse Vincent (<jesse@bestpractical.com>) 和 Craig A. Berry (<craigberry@mac.com>) 修改。
perl(1)、perldebug(1)、perldiag(1)、perlport(1)、perltrap(1)、diff(1)、patch(1)、dbx(1)、gdb(1)
無已知錯誤（猜猜看是用什麼來報告這些錯誤的？）