perlthanks - En ligne dans le Cloud

PROGRAMME:

Nom

perlbug - comment soumettre des rapports de bogues sur Perl

SYNOPSIS

bug perl

bug perl [ -v ] [ -a propos ] [ -s sujet ] [ -b corps | -f fichier d'entrée ] [ -F fichier de sortie ]
[ -r adresse de retour ] [ -e éditeur ] [ -c adminadresse | -C ] [ -S ] [ -t ] [ -d ] [ -A ]
[ -h ] [ -T ]

bug perl [ -v ] [ -r adresse de retour ]
[ -A ] [ -d'accord | -d'accord | -non | -pas d'accord ]

merci

DESCRIPTION

Ce programme est conçu pour vous aider à générer et envoyer des rapports de bogues (et des notes de remerciement)
à propos de perl5 et des modules qui l'accompagnent.

Dans la plupart des cas, vous pouvez simplement l'exécuter de manière interactive à partir d'une ligne de commande sans aucune
arguments et suivez les invites.

Si vous avez trouvé un bogue avec un port non standard (celui qui ne faisait pas partie du Standard
pour la distribution), une distribution binaire ou un module non central (tel que Tk, DBI, etc.), puis
veuillez consulter la documentation fournie avec cette distribution pour déterminer le bon
endroit pour signaler les bogues.

Si vous ne pouvez pas envoyer votre rapport en utilisant bug perl (probablement parce que votre système
n'a pas de moyen d'envoyer du courrier que perlbug reconnaît), vous pourrez peut-être utiliser cet outil
pour composer votre rapport et l'enregistrer dans un fichier que vous pourrez ensuite envoyer à [email protected]
en utilisant votre client de messagerie habituel.

Dans des cas extrêmes, bug perl peut ne pas fonctionner assez bien sur votre système pour vous guider à travers
rédiger un rapport de bogue. Dans ces cas, vous pourrez peut-être utiliser bug perl -d obtenir le système
informations de configuration à inclure dans un rapport de bogue composé manuellement pour
[email protected].

Lorsque vous signalez un bogue, veuillez parcourir cette liste de contrôle :

Quelle version de Perl utilisez-vous ?
Tapez "perl -v" sur la ligne de commande pour le savoir.

Utilisez-vous la dernière version publiée de perl ?
Regarde http://www.perl.org/ découvrir. Si vous n'utilisez pas la dernière version
version, veuillez essayer de reproduire votre bogue sur la dernière version stable.

Notez que les rapports sur les bogues dans les anciennes versions de Perl, en particulier ceux qui indiquent
vous n'avez pas non plus testé la version stable actuelle de Perl, vous recevrez probablement moins
l'attention des volontaires qui construisent et maintiennent Perl que les rapports sur les bogues dans
la version actuelle.

Cet outil n'est pas approprié pour signaler les bogues dans les versions antérieures à Perl 5.0.

Êtes-vous sûr que ce que vous avez est un bug ?
Un nombre important des rapports de bogues que nous recevons s'avèrent être des fonctionnalités documentées dans
Perl. Assurez-vous que le problème que vous rencontrez n'est pas intentionnel en parcourant les
documentation fournie avec la distribution Perl.

Compte tenu du volume considérable de documentation Perl, ce n'est pas une entreprise triviale, mais si
vous pouvez pointer vers la documentation qui suggère que le comportement que vous voyez est mal,
votre problème est susceptible de recevoir plus d'attention. Vous voudrez peut-être commencer par perldoc
perltrap pour les pointeurs vers les pièges courants que les programmeurs Perl nouveaux (et expérimentés) exécutent
dans.

Si vous n'êtes pas sûr de la signification d'un message d'erreur que vous avez rencontré, perldoc
perldiag pour une explication. Si le message n'est pas dans perldiag, ce n'est probablement pas
généré par Perl. Vous pouvez avoir de la chance en consultant la documentation de votre système d'exploitation
à la place.

Si vous êtes sur une plateforme non UNIX perldoc perlport, car certaines fonctionnalités peuvent être
non mis en œuvre ou fonctionnent différemment.

Vous pourrez peut-être comprendre ce qui ne va pas en utilisant le débogueur Perl. Pour
informations sur l'utilisation du débogueur perldoc perldebug.

Avez-vous un cas de test approprié?
Plus il est facile de reproduire votre bogue, plus il est probable qu'il sera corrigé -- si personne
peut dupliquer votre problème, il ne sera probablement pas résolu.

Un bon cas de test possède la plupart de ces attributs : un code court et simple ; peu de dépendances
commandes, modules ou bibliothèques externes ; pas de code dépendant de la plate-forme (sauf s'il s'agit d'un
bogue spécifique à la plate-forme); documentation claire et simple.

Un bon cas de test est presque toujours un bon candidat pour être inclus dans le test de Perl
suite. Si vous avez le temps, pensez à rédiger votre scénario de test afin qu'il puisse être facilement
inclus dans la suite de tests standard.

Avez-vous inclus toutes les informations pertinentes?
Assurez-vous d'inclure le exacte messages d'erreur, le cas échéant. "Perl a donné une erreur" n'est pas un
message d'erreur exact.

Si vous obtenez un core dump (ou équivalent), vous pouvez utiliser un débogueur (dbx, gdb, etc.) à
produire une trace de pile à inclure dans le rapport de bogue.

REMARQUE : à moins que votre Perl n'ait été compilé avec des informations de débogage (souvent -g), la trace de la pile
est susceptible d'être quelque peu difficile à utiliser car il ne contiendra très probablement que le
les noms de fonction et non leurs arguments. Si possible, recompilez votre Perl avec debug
info et reproduire le crash et la trace de la pile.

Pouvez-vous décrire le bogue en anglais simple ?
Plus il est facile de comprendre un bogue reproductible, plus il est probable qu'il sera corrigé.
Toute idée que vous pouvez fournir sur le problème sera d'une grande aide. En d'autres termes,
essayez d'analyser le problème (dans la mesure du possible) et rapportez vos découvertes.

Pouvez-vous corriger le bug vous-même ?
Si c'est le cas, c'est une excellente nouvelle ; les rapports de bogues avec des correctifs sont susceptibles de recevoir de manière significative
plus d'attention et d'intérêt que ceux sans patchs. Veuillez joindre votre patch à
le rapport en utilisant l'option "-p". Lors de l'envoi d'un patch, créez-le en utilisant "git
format-patch" si possible, bien qu'un diff unifié créé avec "diff -pu" fera l'affaire
presque aussi.

Votre patch peut être retourné avec des demandes de modifications ou des demandes de détails plus détaillés.
des explications sur votre correctif.

Voici quelques conseils pour créer des correctifs de haute qualité :

Assurez-vous que le patch n'est pas inversé (le premier argument de diff est généralement le
fichier d'origine, le deuxième argument de votre fichier modifié). Assurez-vous de tester votre patch
en l'appliquant avec "git am" ou le programme "patch" avant de l'envoyer.
Essayez de suivre le même style que le code que vous essayez de corriger. Assurez-vous que votre
patch fonctionne vraiment ("make test", si la chose que vous corrigez est couverte par Perl's
suite de tests).

Pouvez-vous utiliser "perlbug" pour soumettre le rapport ?
bug perl veillera, entre autres, à ce que votre rapport contienne des informations cruciales
à propos de votre version de perl. Si "perlbug" n'est pas en mesure d'envoyer votre rapport après avoir
tapé, vous devrez peut-être composer le message vous-même, ajouter la sortie produite par
"perlbug -d" et envoyez-le à [email protected]. Si, pour une raison quelconque, vous ne pouvez pas exécuter
"perlbug" sur votre système, assurez-vous d'inclure l'intégralité de la sortie produite par
exécuter "perl -V" (notez le V majuscule).

Que vous utilisiez "perlbug" ou que vous envoyiez l'e-mail manuellement, veuillez créer votre ligne d'objet
informatif. "un bug" n'est pas informatif. Ni "perl plante" ni "HELP !!!".
Ceux-ci n'aident pas. Une description compacte de ce qui ne va pas est très bien.

Pouvez-vous utiliser "perlbug" pour envoyer une note de remerciement ?
Oui, vous pouvez le faire soit en utilisant l'option "-T", soit en appelant le programme comme
"merci". Les notes de remerciement sont bonnes. Cela fait sourire les gens.

Après avoir fait votre part, soyez prêt à attendre, qu'on vous dise que le bogue est dans votre code, ou
peut-être pour ne pas avoir de réponse du tout. Les bénévoles qui maintiennent Perl sont des gens très occupés, donc si
votre problème est un bogue évident dans votre propre code, est difficile à comprendre ou est un
duplicata d'un rapport existant, il se peut que vous ne receviez pas de réponse personnelle.

S'il est important pour vous que votre bogue soit corrigé, surveillez le [email protected]
liste de diffusion (les listes de diffusion sont modérées, votre message peut mettre un certain temps à s'afficher) et
les journaux de commit aux versions de développement de Perl, et encouragent les mainteneurs à
mots ou offres de boissons glacées. (Veuillez être gentil avec les responsables. Harceler ou
les enflammer est susceptible d'avoir l'effet inverse de celui que vous voulez.)

N'hésitez pas à mettre à jour le ticket concernant votre bug sur http://rt.perl.org si une nouvelle version de
Perl est sorti et votre bug est toujours présent.

OPTIONS

-a Adresse à laquelle envoyer le rapport. Par défaut à [email protected].

-A N'envoyez pas d'accusé de réception de bogue à l'adresse de réponse. En général c'est
n'est judicieux d'utiliser cette option que si vous êtes un mainteneur de perl qui regarde activement
perl porters pour que votre message arrive.

-b Corps du rapport. S'il n'est pas inclus dans la ligne de commande ou dans un fichier avec -f,
vous aurez la possibilité de modifier le message.

-C N'envoyez pas de copie à l'administrateur.

-c Adresse à laquelle envoyer une copie du rapport. Par défaut l'adresse du perl local
administrateur (enregistré lorsque perl a été construit).

-d Mode données (par défaut si vous redirigez ou dirigez la sortie). Cela imprime votre
données de configuration, sans rien envoyer. Vous pouvez l'utiliser avec -v obtenir
données plus complètes.

-e Editeur à utiliser.

-f Fichier contenant le corps du rapport. Utilisez-le pour envoyer rapidement un
par voie électronique.

-F Fichier dans lequel afficher les résultats au lieu de les envoyer par e-mail. Utile en particulier
lors de l'exécution de perlbug sur une machine sans connexion Internet directe.

-h Imprime un bref résumé des options.

-d'accord Signalez la réussite de la construction de ce système aux porteurs de perl. Les forces -S ainsi que -C. Les forces
et fournit des valeurs pour -s ainsi que -b. Ne demande une adresse de retour que si elle ne peut pas
devinez (à utiliser avec a prendre une). Adresse de retour d'honneur spécifiée avec -r. Vous pouvez
utilisez ceci avec -v pour obtenir des données plus complètes. Ne fait un rapport que si ce système
a moins de 60 jours.

-d'accord As -d'accord sauf qu'il fera rapport sur les systèmes plus anciens.

-non Signaler une construction infructueuse sur ce système. Les forces -C. Force et fournit une valeur
pour -s, vous demande ensuite de modifier le rapport et de dire ce qui s'est mal passé.
Alternativement, un rapport préparé peut être fourni en utilisant -f. Seuls les invites pour un
adresse de retour s'il ne peut pas la deviner (à utiliser avec a prendre une). Adresse de retour des honneurs
spécifié avec -r. Vous pouvez l'utiliser avec -v pour obtenir des données plus complètes. Seul
fait un rapport si ce système a moins de 60 jours.

-pas d'accord As -non sauf qu'il fera rapport sur les systèmes plus anciens.

-p Les noms d'un ou plusieurs fichiers de correctifs ou d'autres pièces jointes de texte à inclure avec
le rapport. Les fichiers multiples doivent être séparés par des virgules.

-r Votre adresse de retour. Le programme vous demandera de confirmer sa valeur par défaut si vous ne
utilisez cette option.

-S Envoyer sans demander de confirmation.

-s Sujet à inclure avec le message. Vous serez invité si vous n'en fournissez pas un
sur la ligne de commande.

-t Mode d'essai. L'adresse cible par défaut est [email protected].

-T Envoyez une note de remerciement au lieu d'un rapport de bogue.

-v Incluez les données de configuration détaillées dans le rapport.

AUTEURS

Kenneth Albanowski ([email protected]>), par la suite dockdéchiré par Gurusamy Sarathy
(<[email protected]>), Tom Christiansen ([email protected]>), Nathan Torkington
(<[email protected]>), Charles F. Randall ([email protected]>), Mike Guy ([email protected]>),
Dominique Dunlop ([email protected]>), Hugo van der Sanden ([email protected]>), Jarkko
Hietaniemi ([email protected]>), Chris Nandor ([email protected]>), Jon Orwan
(<[email protected]>, Richard Foley ([email protected]>), Jesse Vincent
(<[email protected]>), et Craig A. Berry ([email protected]>).

Utilisez perlthanks en ligne en utilisant les services onworks.net