From: Jesse Vincent Date: Sat, 7 Jun 2008 17:10:28 +0000 (-0400) Subject: perlbug prose patch (and some evals, too) X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?a=commitdiff_plain;h=4d5692de8d33e3f52bd85bef7bcdbdffa4ac80e5;p=p5sagit%2Fp5-mst-13.2.git perlbug prose patch (and some evals, too) Message-Id: <89557793-48C2-4962-BE7A-24DC2EAFAF15@fsck.com> (applied to perlbug.PL instead of the generated perlbug) p4raw-id: //depot/perl@34019 --- diff --git a/utils/perlbug.PL b/utils/perlbug.PL index 49792f1..0e92315 100644 --- a/utils/perlbug.PL +++ b/utils/perlbug.PL @@ -90,18 +90,18 @@ use File::Basename 'basename'; sub paraprint; BEGIN { - eval "use Mail::Send;"; + eval { require Mail::Send;}; $::HaveSend = ($@ eq ""); - eval "use Mail::Util;"; + eval { require Mail::Util; } ; $::HaveUtil = ($@ eq ""); # use secure tempfiles wherever possible - eval "require File::Temp;"; + eval { require File::Temp; }; $::HaveTemp = ($@ eq ""); eval { require Module::CoreList; }; $::HaveCoreList = ($@ eq ""); }; -my $Version = "1.36"; +my $Version = "1.37"; # Changed in 1.06 to skip Mail::Send and Mail::Util if not available. # Changed in 1.07 to see more sendmail execs, and added pipe output. @@ -142,7 +142,8 @@ my $Version = "1.36"; # Changed in 1.34 Added Message-Id RFOLEY 18-06-2002 # Changed in 1.35 Use File::Temp (patch from Solar Designer) NWCLARK 28-02-2004 # Changed in 1.36 Initial Module::CoreList support Alexandr Ciornii 11-07-2007 - +# Changed in 1.37 Killed some string evals, rewrote most prose JESSE 06-08-2008 +# # TODO: - Allow the user to re-name the file on mail failure, and # make sure failure (transmission-wise) of Mail::Send is # accounted for. @@ -232,7 +233,7 @@ sub Init { $Is_MacOS = $^O eq 'MacOS'; @ARGV = split m/\s+/, - MacPerl::Ask('Provide command-line args here (-h for help):') + MacPerl::Ask('Provide command line args here (-h for help):') if $Is_MacOS && $MacPerl::Version =~ /App/; if (!getopts("Adhva:s:b:f:F:r:e:SCc:to:n:T")) { Help(); exit; }; @@ -384,38 +385,36 @@ If you wish to submit a bug report, please run it without the -T flag EOF } else { paraprint <<"EOF"; -This program provides an easy way to create a message reporting a bug -in perl, and e-mail it to $address. It is *NOT* intended for -sending test messages or simply verifying that perl works, *NOR* is it -intended for reporting bugs in third-party perl modules. It is *ONLY* -a means of reporting verifiable problems with the core perl distribution, -and any solutions to such problems, to the people who maintain perl. - -If you're just looking for help with perl, try posting to the Usenet -newsgroup comp.lang.perl.misc. If you're looking for help with using -perl with CGI, try posting to comp.infosystems.www.programming.cgi. - -When invoked as perlthanks (or with the -T option) it can be used to -send a thank-you message to $thanksaddress. +This program provides an easy way to create a message reporting a +bug in the core perl distribution (along with tests or patches) +to the volunteers who maintain perl at $address. To send a thank-you +note to $thanksaddress instead of a bug report, please run 'perlthanks'. + +Please do not use $0 to send test messages, test whether perl +works, or use it to report bugs in external perl modules. + +For help using perl, try posting to the Usenet newsgroup +comp.lang.perl.misc. EOF } } # Prompt for subject of message, if needed - if (TrivialSubject($subject)) { + if ($subject && TrivialSubject($subject)) { $subject = ''; } unless ($subject) { - if ($thanks) { - paraprint "First of all, please provide a subject for the message.\n"; - } else { + print +"First of all, please provide a subject for the message.\n"; + if ( not $thanks) { paraprint <; @@ -514,41 +515,40 @@ EOF editor: unless ($::opt_e || $::opt_f || $::opt_b) { chomp (my $common_end = <<"EOF"); - -You will probably want to use an editor to enter -the report. If "$ed" is the editor you want -to use, then just press Enter, otherwise type in -the name of the editor you would like to use. - -If you would like to use a prepared file, type -"file", and you will be asked for the filename. +You will probably want to use a text editor to enter the body of +your report. If "$ed" is the editor you want to use, then just press +Enter, otherwise type in the name of the editor you would like to +use. + +If you have already composed the body of your report, you may enter +"file" "file", and Perlbug will prompt you for to enter the name +of the file containing your report. EOF if ($thanks) { paraprint <<"EOF"; -Now you need to supply your thank-you message. +It's now time to compose your thank-you message. -Some information about your local perl configuration -will automatically be included at the end of the message, -because we're curious about the different ways that people -build perl, but you're welcome to delete it if you wish. +Some information about your local perl configuration will automatically +be included at the end of your message, because we're curious about +the different ways that people build and use perl. If you'd rather +not share this information, you're welcome to delete it. $common_end EOF } else { paraprint <<"EOF"; -Now you need to supply the bug report. Try to make -the report concise but descriptive. Include any -relevant detail. If you are reporting something -that does not work as you think it should, please -try to include example of both the actual -result, and what you expected. - -Some information about your local -perl configuration will automatically be included -at the end of the report. If you are using any -unusual version of perl, please try and confirm -exactly which versions are relevant. +It's now time to compose your bug report. Try to make the report +concise but descriptive. Please include any detail which you think +might be relevant or might help the volunteers working to improve +perl. If you are reporting something that does not work as you think +it should, please try to include example of both the actual result, +and what you expected. + +Some information about your local perl configuration will automatically +be included at the end of your report. If you are using an unusual +version of perl, it would be useful if you could confirm that you +can replicate the problem on a standard build of perl as well. $common_end EOF @@ -568,7 +568,9 @@ EOF my $report_about_module = ''; if ($::HaveCoreList && !$ok && !$thanks) { paraprint <; @@ -580,10 +582,9 @@ EOF my $first_release = Module::CoreList->first_release($entry); unless ($first_release) { paraprint <; @@ -794,8 +799,8 @@ EOF goto tryagain; } else { paraprint <); @@ -838,18 +844,23 @@ sub NowWhat { # Report is done, prompt for further action if( !$::opt_S ) { while(1) { - paraprint <; chomp $action; - + print "\n"; if ($action =~ /^(f|sa)/i) { # ile/ve my $file_save = $outfile || "$progname.rep"; print "\n\nName of file to save message in [$file_save]: "; @@ -871,7 +882,10 @@ EOF close(REP) or die "Error closing report file '$filename': $!"; close(FILE) or die "Error closing $file: $!"; - print "\nMessage saved in '$file'.\n"; + paraprint <isplay, ist, ow # Display the message @@ -879,9 +893,8 @@ EOF while () { print $_ } close(REP) or die "Error closing report file '$filename': $!"; } elsif ($action =~ /^su/i) { # bject - print "Subject: $subject\n"; - print "If the above subject is fine, just press Enter.\n"; - print "If not, type in the new subject.\n"; + print "Subject: $subject\n\n"; + print "If the above subject is fine, press Enter. Otherwise, type a replacement now\n"; print "Subject: "; my $reply = scalar ; chomp $reply; @@ -897,13 +910,13 @@ EOF . 'Please type "yes" if you are: '; my $reply = scalar ; chomp $reply; - if ($reply eq "yes") { + if ($reply =~ /^yes$/) { last; } else { paraprint <dit, e-edit @@ -913,7 +926,7 @@ EOF Cancel(); } elsif ($action =~ /^s/i) { paraprint < + B S<[ B<-v> ]> S<[ B<-a> I
]> S<[ B<-s> I ]> S<[ B<-b> I | B<-f> I ]> S<[ B<-F> I ]> S<[ B<-r> I ]> @@ -1115,25 +1135,29 @@ B S<[ B<-v> ]> S<[ B<-r> I ]> =head1 DESCRIPTION -A program to help generate bug reports about perl or the modules that -come with it, and mail them. -If you have found a bug with a non-standard port (one that was not part -of the I), a binary distribution, or a -non-standard module (such as Tk, CGI, etc), then please see the -documentation that came with that distribution to determine the correct -place to report bugs. +This program is designed to help you generate and send bug reports +(and thank-you notes) about perl5 and the modules which ship with it. -C is designed to be used interactively. Normally no arguments -will be needed. Simply run it, and follow the prompts. +In most cases, you can just run it interactively from a command +line without any special arguments and follow the prompts. -If you are unable to run B (most likely because you don't have -a working setup to send mail that perlbug recognizes), you may have to -compose your own report, and email it to B. You might -find the B<-d> option useful to get summary information in that case. +If you have found a bug with a non-standard port (one that was not +part of the I), a binary distribution, or a +non-core module (such as Tk, DBI, etc), then please see the +documentation that came with that distribution to determine the +correct place to report bugs. -In any case, when reporting a bug, please make sure you have run through -this checklist: +If you are unable to send your report using B (most likely +because your system doesn't have a way to send mail that perlbug recognizes), you may be able to use this tool to compose your report and save it to a file +which you can then send to B using your regular mail client. + +In extreme cases, B may not work well enough on your system to +guide you through composing a bug report. In those cases, you may be able to +use B to get system configuration information to include in a manually composed bug report to B. + + +When reporting a bug, please run through this checklist: =over 4 @@ -1143,110 +1167,131 @@ Type C at the command line to find out. =item Are you running the latest released version of perl? -Look at http://www.perl.com/ to find out. If it is not the latest -released version, get that one and see whether your bug has been -fixed. Note that bug reports about old versions of Perl, especially -those prior to the 5.0 release, are likely to fall upon deaf ears. -You are on your own if you continue to use perl1 .. perl4. +Look at http://www.perl.org/ to find out. If you are not using the +latest released version, please try to replicate your bug on the +latest stable release. + +Note that bug reports about old versions of Perl, especially those +tested only on versions of Perl prior to the current stable release, +are likely to receive less attention from the volunteers who build +and maintain Perl than bugs in the current release. + +This tool isn't apropriate for reporting bugs in any version of +prior to Perl 5.0. =item Are you sure what you have is a bug? -A significant number of the bug reports we get turn out to be documented -features in Perl. Make sure the behavior you are witnessing doesn't fall -under that category, by glancing through the documentation that comes -with Perl (we'll admit this is no mean task, given the sheer volume of -it all, but at least have a look at the sections that I relevant). +A significant number of the bug reports we get turn out to be +documented features in Perl. Make sure the issue you've run into +isn't intentional by glancing through the documentation that comes +with the Perl distribution. -Be aware of the familiar traps that perl programmers of various hues -fall into. See L. +Given the sheer volume of Perl documentation, this isn't a trivial +undertaking, but if you can point to documentation that suggests +the behaviour you're seeing is I, your issue is likely to +receive more attention. You may want to start with B +L for pointers to common traps that new (and experienced) +Perl programmers run into. -Check in L to see what any Perl error message(s) mean. -If message isn't in perldiag, it probably isn't generated by Perl. -Consult your operating system documentation instead. +If you're unsure of them meaning of an error message you've run +across, B L for an explanation. If message isn't +in perldiag, it probably isn't generated by Perl. You may have +luck consulting your operating system documentation instead. -If you are on a non-UNIX platform check also L, as some +If you are on a non-UNIX platform B L, as some features may be unimplemented or work differently. -Try to study the problem under the Perl debugger, if necessary. -See L. +You may be able to figure out what's going wrong using the Perl +debugger. For information about how to use the debugger B +L. =item Do you have a proper test case? The easier it is to reproduce your bug, the more likely it will be -fixed, because if no one can duplicate the problem, no one can fix it. -A good test case has most of these attributes: fewest possible number -of lines; few dependencies on external commands, modules, or -libraries; runs on most platforms unimpeded; and is self-documenting. +fixed -- If nobody can duplicate your problem, it probably won't be +addressed. + +A good test case has most of these attributes: short, simple code; +few dependencies on external commands, modules, or libraries; no +platform-dependent code (unless it's a platform-specific bug); +clear, simple documentation. -A good test case is almost always a good candidate to be on the perl -test suite. If you have the time, consider making your test case so -that it will readily fit into the standard test suite. +A good test case is almost always a good candidate to be included in +Perl's test suite. If you have the time, consider writing your test case so +that it can be easily included into the standard test suite. -Remember also to include the B error messages, if any. -"Perl complained something" is not an exact error message. +=item Have you included all relevant information? + +Be sure to include the B error messages, if any. +"Perl gave an error" is not an exact error message. If you get a core dump (or equivalent), you may use a debugger (B, B, etc) to produce a stack trace to include in the bug -report. NOTE: unless your Perl has been compiled with debug info +report. + +NOTE: unless your Perl has been compiled with debug info (often B<-g>), the stack trace is likely to be somewhat hard to use because it will most probably contain only the function names and not their arguments. If possible, recompile your Perl with debug info and -reproduce the dump and the stack trace. +reproduce the crash and the stack trace. =item Can you describe the bug in plain English? -The easier it is to understand a reproducible bug, the more likely it -will be fixed. Anything you can provide by way of insight into the -problem helps a great deal. In other words, try to analyze the -problem (to the extent you can) and report your discoveries. +The easier it is to understand a reproducible bug, the more likely +it will be fixed. Any insight you can provide into the problem +will help a great deal. In other words, try to analyze the problem +(to the extent you can) and report your discoveries. =item Can you fix the bug yourself? A bug report which I will almost -definitely be fixed. Use the C program to generate your patches -(C is being maintained by the GNU folks as part of the B -package, so you should be able to get it from any of the GNU software -repositories). If you do submit a patch, the cool-dude counter at -perlbug@perl.org will register you as a savior of the world. Your -patch may be returned with requests for changes, or requests for more +definitely be fixed. When sending a patch, please use the C +program with the C<-u> option to generate "unified" diff files. +Bug reports with patches are likely to receive significantly more +attention and interest than those without patches. + +Your patch may be returned with requests for changes, or requests for more detailed explanations about your fix. -Here are some clues for creating quality patches: Use the B<-c> or -B<-u> switches to the diff program (to create a so-called context or -unified diff). Make sure the patch is not reversed (the first -argument to diff is typically the original file, the second argument -your changed file). Make sure you test your patch by applying it with -the C program before you send it on its way. Try to follow the -same style as the code you are trying to patch. Make sure your patch -really does work (C, if the thing you're patching supports -it). +Here are a few hints for creating high-quality patches: + +Make sure the patch is not reversed (the first argument to diff is +typically the original file, the second argument your changed file). +Make sure you test your patch by applying it with the C +program before you send it on its way. Try to follow the same style +as the code you are trying to patch. Make sure your patch really +does work (C, if the thing you're patching is covered +by Perl's test suite). =item Can you use C to submit the report? B will, amongst other things, ensure your report includes -crucial information about your version of perl. If C is unable -to mail your report after you have typed it in, you may have to compose -the message yourself, add the output produced by C and email -it to B. If, for some reason, you cannot run -C at all on your system, be sure to include the entire output -produced by running C (note the uppercase V). +crucial information about your version of perl. If C is +unable to mail your report after you have typed it in, you may have +to compose the message yourself, add the output produced by C and email it to B. If, for some reason, you +cannot run C at all on your system, be sure to include the +entire output produced by running C (note the uppercase V). Whether you use C or send the email manually, please make -your Subject line informative. "a bug" not informative. Neither is -"perl crashes" nor "HELP!!!". These don't help. -A compact description of what's wrong is fine. +your Subject line informative. "a bug" not informative. Neither +is "perl crashes" nor is "HELP!!!". These don't help. A compact +description of what's wrong is fine. =back Having done your bit, please be prepared to wait, to be told the bug -is in your code, or even to get no reply at all. The Perl maintainers -are busy folks, so if your problem is a small one or if it is difficult -to understand or already known, they may not respond with a personal reply. -If it is important to you that your bug be fixed, do monitor the -C file in any development releases since the time you submitted -the bug, and encourage the maintainers with kind words (but never any -flames!). Feel free to resend your bug report if the next released -version of perl comes out and your bug is still present. +is in your code, or possibly to get no reply at all. The volunteers who +maintain Perl are busy folks, so if your problem is an obvious bug in your own code, is difficult to understand or is a duplicate of an existing report, you +may not receive a personal reply. + +If it is important to you that your bug be fixed, do monitor the perl5-porters@perl.org mailing list, the commit logs to development versions of Perl +and encourage the maintainers with kind words or offers of frosty beverages. +(Please do be kind to the maintainers. Harassing or flaming them is likely to +have the opposite effect of the one you want.) + +Feel free update the ticket about your bug on http://rt.perl.org +if a new version of Perl is released and your bug is still present. =head1 OPTIONS @@ -1356,15 +1401,16 @@ Include verbose configuration data in the report. =head1 AUTHORS -Kenneth Albanowski (Ekjahds@kjahds.comE), subsequently Itored -by Gurusamy Sarathy (Egsar@activestate.comE), Tom Christiansen -(Etchrist@perl.comE), Nathan Torkington (Egnat@frii.comE), -Charles F. Randall (Ecfr@pobox.comE), Mike Guy -(Emjtg@cam.a.ukE), Dominic Dunlop (Edomo@computer.orgE), -Hugo van der Sanden (Ehv@crypt.org), +Kenneth Albanowski (Ekjahds@kjahds.comE), subsequently +Itored by Gurusamy Sarathy (Egsar@activestate.comE), +Tom Christiansen (Etchrist@perl.comE), Nathan Torkington +(Egnat@frii.comE), Charles F. Randall (Ecfr@pobox.comE), +Mike Guy (Emjtg@cam.a.ukE), Dominic Dunlop +(Edomo@computer.orgE), Hugo van der Sanden (Ehv@crypt.org), Jarkko Hietaniemi (Ejhi@iki.fiE), Chris Nandor (Epudge@pobox.comE), Jon Orwant (Eorwant@media.mit.eduE, -and Richard Foley (Erichard@rfi.netE). +Richard Foley (Erichard@rfi.netE), and Jesse Vincent +(Ejesse@bestpractical.com). =head1 SEE ALSO