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 回傳位址 ] [ -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)
無已知 BUG（猜猜看是用什麼工具回報的？）