perlthanks - Online na nuvem

PROGRAMA:

NOME

perlbug - como enviar relatórios de bug no Perl

SINOPSE

perlbug

perlbug [ -v ] [ -a endereço ] [ -s sujeito ] [ -b corpo | -f Arquivo de entrada ] [ -F arquivo de saída ]
[ -r endereço de devolução ] [ -e editor ] [ -c endereço de administrador | -C ] [ -S ] [ -t ] [ -d ] [ -A ]
[ -h ] [ -T ]

perlbug [ -v ] [ -r endereço de devolução ]
[ -A ] [ -OK | -Certo | -não | -não ]

muito obrigado

DESCRIÇÃO

Este programa foi projetado para ajudá-lo a gerar e enviar relatórios de erros (e notas de agradecimento)
sobre o perl5 e os módulos que o acompanham.

Na maioria dos casos, você pode simplesmente executá-lo interativamente a partir de uma linha de comando sem qualquer
argumentos e siga as instruções.

Se você encontrou um bug com uma porta não padrão (uma que não fazia parte do padrão
distribuição), uma distribuição binária ou um módulo não principal (como Tk, DBI, etc), então
por favor, consulte a documentação que veio com essa distribuição para determinar o correto
lugar para relatar bugs.

Se você não puder enviar seu relatório usando perlbug (provavelmente porque o seu sistema
não tem uma maneira de enviar e-mail que perlbug reconheça), você pode usar esta ferramenta
para redigir seu relatório e salvá-lo em um arquivo que você pode enviar para [email protegido]
usando seu cliente de e-mail normal.

Em casos extremos, perlbug pode não funcionar bem o suficiente em seu sistema para guiá-lo através
redigindo um relatório de bug. Nesses casos, você pode usar perlbug -d obter sistema
informações de configuração para incluir em um relatório de bug composto manualmente para
[email protegido].

Ao relatar um bug, execute esta lista de verificação:

Qual versão do Perl você está executando?
Digite “perl -v” na linha de comando para descobrir.

Você está executando a última versão lançada do perl?
Olhe para http://www.perl.org/ descobrir. Se você não estiver usando o último lançado
versão, tente replicar seu bug na versão estável mais recente.

Observe que os relatórios sobre bugs em versões antigas do Perl, especialmente aqueles que indicam
você também não testou a versão estável atual do Perl, provavelmente receberá menos
atenção dos voluntários que constroem e mantêm Perl do que relatórios sobre bugs em
a versão atual.

Esta ferramenta não é apropriada para relatar bugs em qualquer versão anterior ao Perl 5.0.

Tem certeza de que é um bug?
Um número significativo de relatórios de bugs que obtemos são recursos documentados em
Perl. Certifique-se de que o problema que você encontrou não seja intencional, olhando através do
documentação que vem com a distribuição Perl.

Dado o grande volume de documentação Perl, esta não é uma tarefa trivial, mas se
você pode apontar a documentação que sugere que o comportamento que você está vendo é Wrongs,
seu problema provavelmente receberá mais atenção. Você pode querer começar com perldoc
perltrap para ponteiros para armadilhas comuns que novos (e experientes) programadores Perl executam
em.

Se você não tiver certeza do significado de uma mensagem de erro que encontrou, perldoc
perldiag por uma explicação. Se a mensagem não estiver em perldiag, provavelmente não
gerado por Perl. Você pode ter sorte ao consultar a documentação do seu sistema operacional
ao invés.

Se você estiver em uma plataforma não UNIX perldoc perlport, como alguns recursos podem ser
não implementados ou funcionam de forma diferente.

Você pode descobrir o que está errado usando o depurador Perl. Para
informações sobre como usar o depurador perldoc perldebug.

Você tem um caso de teste adequado?
Quanto mais fácil for reproduzir o seu bug, mais provavelmente ele será corrigido - se ninguém
pode duplicar o seu problema, provavelmente não será resolvido.

Um bom caso de teste tem a maioria destes atributos: código curto e simples; poucas dependências em
comandos externos, módulos ou bibliotecas; nenhum código dependente de plataforma (a menos que seja um
bug específico da plataforma); documentação clara e simples.

Um bom caso de teste é quase sempre um bom candidato a ser incluído no teste de Perl
suíte. Se você tiver tempo, considere escrever seu caso de teste para que possa ser facilmente
incluído no conjunto de testes padrão.

Você incluiu todas as informações relevantes?
Certifique-se de incluir o exato mensagens de erro, se houver. "Perl deu um erro" não é um
mensagem de erro exata.

Se você obtiver um core dump (ou equivalente), você pode usar um depurador (dbx, gdb, etc) para
produzir um rastreamento de pilha para incluir no relatório de bug.

NOTA: a menos que seu Perl tenha sido compilado com informações de depuração (frequentemente -g), o rastreamento de pilha
é provável que seja um pouco difícil de usar porque provavelmente conterá apenas o
nomes de funções e não seus argumentos. Se possível, recompile seu Perl com depuração
informações e reproduzir a falha e o rastreamento de pilha.

Você pode descrever o bug em inglês simples?
Quanto mais fácil for entender um bug reproduzível, maior a probabilidade de ele ser corrigido.
Qualquer insight que você possa fornecer sobre o problema ajudará muito. Em outras palavras,
tente analisar o problema (na medida do possível) e relatar suas descobertas.

Você pode consertar o bug sozinho?
Se for assim, isso é uma ótima notícia; relatórios de bugs com patches podem receber significativamente
mais atenção e interesse do que aqueles sem patches. Por favor, anexe seu patch para
o relatório usando a opção "-p". Ao enviar um patch, crie-o usando "git
format-patch "se possível, embora um diff unificado criado com" diff -pu "servirá
quase tão bem.

Seu patch pode ser devolvido com solicitações de mudanças ou solicitações mais detalhadas
explicações sobre sua correção.

Aqui estão algumas dicas para criar patches de alta qualidade:

Certifique-se de que o patch não seja revertido (o primeiro argumento para diff é tipicamente o
arquivo original, o segundo argumento é o arquivo alterado). Certifique-se de testar seu patch
aplicando-o com "git am" ou o programa "patch" antes de enviá-lo.
Tente seguir o mesmo estilo do código que você está tentando corrigir. Certifique-se de que o seu
patch realmente funciona ("make test", se o que você está corrigindo é coberto por
suíte de teste).

Você pode usar "perlbug" para enviar o relatório?
perlbug irá, entre outras coisas, garantir que seu relatório inclua informações cruciais
sobre sua versão do perl. Se "perlbug" não for capaz de enviar seu relatório após você ter
digitou, você pode ter que redigir a mensagem sozinho, adicionar a saída produzida por
"perlbug -d" e envie por e-mail para [email protegido]. Se, por algum motivo, você não pode executar
"perlbug" em todo o seu sistema, certifique-se de incluir toda a saída produzida por
executando "perl-V" (observe o V maiúsculo).

Se você usar "perlbug" ou enviar o e-mail manualmente, coloque a linha de assunto
informativo. "um bug" não é informativo. Nem é "perl crashes" nem "HELP !!!".
Isso não ajuda. Uma descrição compacta do que está errado está bom.

Você pode usar "perlbug" para enviar uma nota de agradecimento?
Sim, você pode fazer isso usando a opção "-T" ou invocando o programa como
"perlthanks". Notas de agradecimento são boas. Isso faz as pessoas sorrirem.

Tendo feito sua parte, esteja preparado para esperar, para ser informado de que o bug está em seu código, ou
possivelmente para não obter resposta alguma. Os voluntários que mantêm Perl são pessoas ocupadas, então se
seu problema é um bug óbvio em seu próprio código, é difícil de entender ou é um
duplicado de um relatório existente, você não pode receber uma resposta pessoal.

Se é importante para você que seu bug seja corrigido, monitore o [email protegido]
lista de discussão (listas de discussão são moderadas, sua mensagem pode demorar um pouco para aparecer) e
os logs de confirmação para versões de desenvolvimento do Perl, e encoraja os mantenedores com gentileza
palavras ou ofertas de bebidas geladas. (Por favor, seja gentil com os mantenedores. Assédio ou
flamejá-los provavelmente terá o efeito oposto ao que você deseja.)

Sinta-se à vontade para atualizar o tíquete sobre o bug em http://rt.perl.org se uma nova versão de
Perl foi lançado e seu bug ainda está presente.

OPÇÕES

-a Endereço para o qual enviar o relatório. Padrões para [email protegido].

-A Não envie uma confirmação de bug recebido para o endereço de resposta. Geralmente é
só é sensato usar esta opção se você for um mantenedor de perl observando ativamente
perl porters para que sua mensagem chegue.

-b Corpo do relatório. Se não estiver incluído na linha de comando, ou em um arquivo com -f,
você terá a chance de editar a mensagem.

-C Não envie cópia para o administrador.

-c Endereço para o qual enviar cópia do relatório. O padrão é o endereço do perl local
administrador (registrado quando o perl foi construído).

-d Modo de dados (o padrão se você redirecionar ou direcionar a saída). Isso imprime seu
dados de configuração, sem enviar nada. Você pode usar isso com -v para obter
dados mais completos.

-e Editor para usar.

-f Arquivo contendo o corpo do relatório. Use isso para enviar rapidamente um
mensagem.

-F Arquivo para enviar os resultados em vez de enviá-los por e-mail. Particularmente útil
ao executar o perlbug em uma máquina sem conexão direta com a Internet.

-h Imprime um breve resumo das opções.

-OK Relate uma construção bem-sucedida neste sistema para perl porters. Forças -S e -C. Forças
e fornece valores para -s e -b. Só pede um endereço de devolução se não puder
adivinhe (para usar com fazer) Endereço de devolução honroso especificado com -r. Você pode
use isso com -v para obter dados mais completos. Só faz um relatório se este sistema
tem menos de 60 dias.

-Certo As -OK exceto que irá relatar em sistemas mais antigos.

-não Reportar construção malsucedida neste sistema. Forças -C. Força e fornece um valor
for -s, então exige que você edite o relatório e diga o que deu errado.
Alternativamente, um relatório preparado pode ser fornecido usando -f. Apenas solicita um
endereço de retorno se não puder adivinhá-lo (para uso com fazer) Endereço de devolução honroso
especificado com -r. Você pode usar isso com -v para obter dados mais completos. Somente
faz um relatório se este sistema tiver menos de 60 dias.

-não As -não exceto que irá relatar em sistemas mais antigos.

-p Os nomes de um ou mais arquivos de patch ou outros anexos de texto a serem incluídos com
o relatório. Vários arquivos devem ser separados por vírgulas.

-r Seu endereço de retorno. O programa irá pedir-lhe para confirmar o seu padrão se você não
use esta opção.

-S Envie sem pedir confirmação.

-s Assunto a incluir na mensagem. Você será questionado se não fornecer um
na linha de comando.

-t Modo de teste. O endereço de destino padrão é [email protegido].

-T Envie uma nota de agradecimento em vez de um relatório de bug.

-v Inclua dados de configuração detalhados no relatório.

AUTORES

Kenneth Albanowski ([email protegido]>), posteriormente docatored por Gurusamy Sarathy
(<[email protegido]>), Tom Christiansen ([email protegido]>), Nathan Torkington
(<[email protegido]>), Charles F. Randall ([email protegido]>), Mike Guy ([email protegido]>),
Dominic Dunlop ([email protegido]>), Hugo van der Sanden ([email protegido]>), Jarkko
Hietaniemi ([email protegido]>), Chris Nandor ([email protegido]>), Jon Orwant
(<[email protegido]>, Richard Foley ([email protegido]>), Jesse Vincent
(<[email protegido]>), e Craig A. Berry ([email protegido]>).

Use perlthanks online usando serviços onworks.net