perlthanks - Online nel cloud

PROGRAMMA:

NOME

perlbug - come inviare segnalazioni di bug su Perl

SINOSSI

perlbug

perlbug [ -v ] [ -a indirizzo ] [ -s soggetto ] [ -b stile di vita | -f file di input ] [ -F file di uscita ]
[ -r indirizzo di ritorno ] [ -e editore ] [ -c indirizzo amministratore | -C ] [ -S ] [ -t ] [ -d ] [ -A ]
[ -h ] [ -T ]

perlbug [ -v ] [ -r indirizzo di ritorno ]
[ -A ] [ -OK | -va bene | -no | - no ]

perlgrazie

DESCRIZIONE

Questo programma è progettato per aiutarti a generare e inviare segnalazioni di bug (e note di ringraziamento)
su perl5 e sui moduli forniti con esso.

Nella maggior parte dei casi, puoi semplicemente eseguirlo in modo interattivo da una riga di comando senza alcuno speciale
argomenti e seguire le istruzioni.

Se hai trovato un bug con una porta non standard (una che non faceva parte del Standard
distribuzione), una distribuzione binaria o un modulo non core (come Tk, DBI, ecc.), quindi
si prega di consultare la documentazione fornita con quella distribuzione per determinare la corretta
luogo per segnalare bug.

Se non riesci a inviare la tua segnalazione utilizzando perlbug (molto probabilmente perché il tuo sistema
non ha un modo per inviare posta che perlbug riconosce), potresti essere in grado di utilizzare questo strumento
per comporre il tuo rapporto e salvarlo in un file che puoi poi inviare a [email protected]
utilizzando il tuo normale client di posta.

In casi estremi, perlbug potrebbe non funzionare abbastanza bene sul tuo sistema per guidarti attraverso
comporre una segnalazione di bug. In questi casi, potresti essere in grado di utilizzare perlbug -d per ottenere il sistema
informazioni di configurazione da includere in una segnalazione di bug composta manualmente a
[email protected].

Quando si segnala un bug, eseguire questa lista di controllo:

Quale versione di Perl stai utilizzando?
Digita "perl -v" nella riga di comando per scoprirlo.

Stai eseguendo l'ultima versione rilasciata di perl?
Guarda a http://www.perl.org/ per scoprirlo. Se non stai utilizzando l'ultima versione rilasciata
versione, prova a replicare il tuo bug sull'ultima versione stabile.

Nota che riporta bug nelle vecchie versioni di Perl, specialmente quelli che indicano
non hai testato anche l'attuale versione stabile di Perl, probabilmente ne riceverai di meno
attenzione da parte dei volontari che costruiscono e mantengono Perl rispetto alle segnalazioni di bug in
la versione attuale.

Questo strumento non è appropriato per segnalare bug in qualsiasi versione precedente a Perl 5.0.

Sei sicuro che quello che hai sia un bug?
Un numero significativo delle segnalazioni di bug che riceviamo risultano essere funzionalità documentate in
Perla. Assicurati che il problema che hai riscontrato non sia intenzionale dando un'occhiata al
documentazione fornita con la distribuzione Perl.

Dato l'enorme volume di documentazione Perl, questa non è un'impresa banale, ma se
puoi puntare alla documentazione che suggerisce che il comportamento che stai vedendo è Wrongs,
è probabile che il tuo problema riceva più attenzione. Potresti iniziare con perldoc
perltrap per i puntatori a trap comuni eseguite dai programmatori Perl nuovi (ed esperti)
in.

Se non sei sicuro del significato di un messaggio di errore che hai riscontrato, perldoc
perldiag per una spiegazione. Se il messaggio non è in perldiag, probabilmente non lo è
generato da Perl. Potresti avere fortuna consultando la documentazione del tuo sistema operativo
anziché.

Se sei su una piattaforma non UNIX perldoc perlport, come potrebbero essere alcune funzionalità
non implementato o funzionano in modo diverso.

Potresti essere in grado di capire cosa non va usando il debugger Perl. Per
informazioni su come utilizzare il debugger perldoc perldebug.

Hai un caso di prova adeguato?
Più è facile riprodurre il tuo bug, più è probabile che venga risolto -- se nessuno
può duplicare il tuo problema, probabilmente non verrà affrontato.

Un buon test case ha la maggior parte di questi attributi: codice breve e semplice; poche dipendenze da
comandi, moduli o librerie esterni; nessun codice dipendente dalla piattaforma (a meno che non sia a
bug specifico della piattaforma); documentazione chiara e semplice.

Un buon test case è quasi sempre un buon candidato per essere incluso nel test di Perl
suite. Se hai tempo, considera di scrivere il tuo caso di prova in modo che possa essere facilmente
incluso nella suite di test standard.

Hai incluso tutte le informazioni rilevanti?
Assicurati di includere il esattamente messaggi di errore, se presenti. "Perl ha dato un errore" non è un
messaggio di errore esatto.

Se ottieni un core dump (o equivalente), puoi usare un debugger (dbx, gdb, ecc) a
produrre una traccia dello stack da includere nella segnalazione di bug.

NOTA: a meno che il tuo Perl non sia stato compilato con informazioni di debug (spesso -g), la traccia dello stack
è probabilmente un po' difficile da usare perché molto probabilmente conterrà solo il
nomi di funzioni e non i loro argomenti. Se possibile, ricompila il tuo Perl con debug
info e riprodurre l'arresto anomalo e la traccia dello stack.

Puoi descrivere il bug in un inglese semplice?
Più è facile capire un bug riproducibile, più è probabile che venga corretto.
Qualsiasi informazione tu possa fornire sul problema sarà di grande aiuto. In altre parole,
prova ad analizzare il problema (per quanto puoi) e riporta le tue scoperte.

Puoi correggere il bug da solo?
Se è così, è un'ottima notizia; è probabile che le segnalazioni di bug con patch ricevano in modo significativo
più attenzione e interesse di quelli senza patch. Allega la tua patch a
il report utilizzando l'opzione "-p". Quando invii una patch, creala usando "git
format-patch" se possibile, anche se un diff unificato creato con "diff -pu" andrà bene
quasi altrettanto.

La tua patch potrebbe essere restituita con richieste di modifiche o richieste di maggiori dettagli
spiegazioni sulla tua correzione.

Ecco alcuni suggerimenti per creare patch di alta qualità:

Assicurati che la patch non sia invertita (il primo argomento per diff è in genere il
file originale, il secondo argomento il file modificato). Assicurati di testare la tua patch
applicandolo con "git am" o il programma "patch" prima di inviarlo sulla sua strada.
Prova a seguire lo stesso stile del codice che stai cercando di patchare. Assicurati che il tuo
patch funziona davvero ("make test", se la cosa che stai patchando è coperta da Perl's
suite di prova).

Puoi usare "perlbug" per inviare il rapporto?
perlbug garantirà, tra le altre cose, che la tua segnalazione contenga informazioni cruciali
sulla tua versione di perl. Se "perlbug" non è in grado di inviare il tuo rapporto dopo che l'hai fatto
digitato, potresti dover comporre tu stesso il messaggio, aggiungere l'output prodotto da
"perlbug -d" e invialo via email a [email protected]. Se, per qualche motivo, non puoi correre
"perlbug" sul tuo sistema, assicurati di includere l'intero output prodotto da
eseguendo "perl -V" (notare la V maiuscola).

Sia che tu usi "perlbug" o che invii l'e-mail manualmente, inserisci la riga dell'oggetto
Informativo. "un bug" non è informativo. Né è "perl crash" né è "AIUTO!!!".
Questi non aiutano. Una descrizione compatta di ciò che è sbagliato va bene.

Puoi usare "perlbug" per inviare una nota di ringraziamento?
Sì, puoi farlo utilizzando l'opzione "-T" o invocando il programma come
"perlgrazie". Le note di ringraziamento sono buone. Fa sorridere le persone.

Dopo aver fatto la tua parte, preparati ad aspettare che ti venga detto che il bug è nel tuo codice, oppure
forse per non ricevere alcuna risposta. I volontari che gestiscono Perl sono persone impegnate, quindi se
il tuo problema è un evidente bug nel tuo codice, è difficile da capire o è un
duplicato di una segnalazione esistente, potresti non ricevere una risposta personale.

Se per te è importante che il tuo bug venga corretto, monitora il [email protected]
mailing list (le mailing list sono moderate, il tuo messaggio potrebbe impiegare un po' di tempo per essere visualizzato) e
i log di commit alle versioni di sviluppo di Perl e incoraggia i manutentori con kind
parole o offerte di bevande ghiacciate. (Si prega di essere gentili con i manutentori. Molestie o
fiammeggiarli probabilmente avrà l'effetto opposto di quello che si desidera.)

Sentiti libero di aggiornare il ticket sul tuo bug su http://rt.perl.org se una nuova versione di
Perl è stato rilasciato e il tuo bug è ancora presente.

VERSIONI

-a Indirizzo a cui inviare la segnalazione. Il valore predefinito è [email protected].

-A Non inviare una conferma di ricezione del bug all'indirizzo di risposta. In genere è
è sensato usare questa opzione solo se sei un manutentore di perl che guarda attivamente
perl porters per l'arrivo del tuo messaggio.

-b Corpo del rapporto. Se non incluso nella riga di comando o in un file con -f,
avrai la possibilità di modificare il messaggio.

-C Non inviare copia all'amministratore.

-c Indirizzo a cui inviare copia del verbale. Il valore predefinito è l'indirizzo del perl . locale
amministratore (registrato quando perl è stato creato).

-d Modalità dati (l'impostazione predefinita se si reindirizza o si reindirizza l'output). Questo stampa il tuo
dati di configurazione, senza inviare nulla. Puoi usarlo con -v ottenere
dati più completi.

-e Editor da utilizzare.

-f File contenente il corpo del report. Usalo per inviare rapidamente un preparato
messaggio.

-F File a cui inviare i risultati invece di inviarli come e-mail. Utile particolarmente
quando si esegue perlbug su una macchina senza connessione Internet diretta.

-h Stampa un breve riepilogo delle opzioni.

-OK Segnala build di successo su questo sistema ai portatori di perl. forze -S che a -C. forze
e fornisce valori per -s che a -b. Richiede un indirizzo di restituzione solo se non è possibile
indovina (da usare con make). Onora l'indirizzo di ritorno specificato con -r. Puoi
usa questo con -v per avere dati più completi. Segnala solo se questo sistema
ha meno di 60 giorni.

-va bene As -OK tranne che riporterà sui sistemi più vecchi.

-no Segnala build non riuscita su questo sistema. forze -C. Forza e fornisce un valore
per -s, quindi richiede di modificare il rapporto e dire cosa è andato storto.
In alternativa, è possibile fornire un rapporto preparato utilizzando -f. Richiede solo a
restituire l'indirizzo se non riesce a indovinarlo (da usare con make). Indirizzo di ritorno degli onori
specificato con -r. Puoi usarlo con -v per avere dati più completi. Soltanto
segnala se questo sistema ha meno di 60 giorni.

- no As -no tranne che riporterà sui sistemi più vecchi.

-p I nomi di uno o più file di patch o altri allegati di testo da includere
il rapporto. Più file devono essere separati da virgole.

-r Il tuo indirizzo di ritorno. Il programma ti chiederà di confermare il suo valore predefinito se non lo fai
utilizzare questa opzione.

-S Invia senza chiedere conferma.

-s Soggetto da includere nel messaggio. Ti verrà chiesto se non ne fornisci uno
sulla riga di comando.

-t Modalità di prova. L'indirizzo di destinazione predefinito è [email protected].

-T Invia una nota di ringraziamento invece di una segnalazione di bug.

-v Includere dati di configurazione dettagliati nel report.

AUTORI

Kenneth Albanowski ([email protected]>), successivamente docstrappato da 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]>), e Craig A. Berry ([email protected]>).

Usa perlthanks online utilizzando i servizi onworks.net