This bug is still present in 5.6. Porters, anyone game to track it down? Nat > This is a bug report for perl from occitan@esperanto.org, > generated with the help of perlbug 1.26 running under perl 5.00502. > ----------------------------------------------------------------- > While you go about this, a little remark. When using =cut a lot it sticks out > like a sore thumb, distracting from the code. It would be neat if (given that > this is a sort of closing paren) qr/\bcut=$/ would perform the same trick. > I'm thinking about writing a Pod.pm parser, which the various incarnations > would inherit from and only worry about the generating-half of the job. > > In the style of literate programming I just mingled the pod into a very long > statement (GetOptions which is several pages long, and I documented every > option on the spot, for one thing to be sure to cover them all, for another to > make the weird option specs clearer). > > The = signs before item and cut are not seen, probably erroneously parsed as > assignments, even though they are on paragraphs of their own. A real pity the > perlpod's assertion "Perl will ignore the pod text." doesn't hold. Silly > example: > > =head1 test > > =over > > =cut > > print > > =item number > > =cut > > 1, > > =item newline > > =cut > > "\n"; > > =back > > gives: > > Number found where operator expected at test.pl line 13, near "cut > > 1" > (Do you need to predeclare cut?) > syntax error at test.pl line 13, near "cut > > 1" > String found where operator expected at test.pl line 19, near "cut > > "\n"" > (Do you need to predeclare cut?) > Execution of test.pl aborted due to compilation errors.Thread Next