Re: Mysterious crash of perldoc

This is happening to me on two machines, one with CentOS 6

I have a couple of CentOS6 boxes and am unable to reproduce your findings.

$ cat foo.pod
#!/usr/bin/perl -w
use strict;

=pod

My documentation.

=cut

$ perldoc -T foo.pod   
FOO(1)                User Contributed Perl Documentation             
+  FOO(1)



My documentation.



perl v5.10.1                      2019-03-14                          
+  FOO(1)
$
[download]

This suggests that either this isn't the POD you are really using or that your perl (or O/S) installation has become badly broken in some way. The fact that you're seeing it on 2 completely different operating systems does rather lean towards the former. Is this the entirety of the POD you are using?

Comment on Re: Mysterious crash of perldoc Download Code

Replies are listed 'Best First'.
Re^2: Mysterious crash of perldoc by Textorix (Acolyte) on Mar 15, 2019 at 00:04 UTC
That's interesting that you're getting different results on another CentOS 6 system using the same POD input. Although my situation seems to have a resolution from the discussion with pryrt, I don't know how to explain why you're getting different results. Yes, that posted POD was literally one of the cases in which I was getting an error 1 status exit from the "perldoc -F" command. When I added a =head1 element to the file, that was the main thing that resolved the error. The file processes OK with or without the =pod element, but the lack of a =head1 or something similar seems to trigger the error. I also had to fix the options to my PERLDOC_PAGER in order to see the output without the pager exiting immediately. Edit 1 Oh... one possibility might be that you're saving the text as a .pod file, whereas I had it in a .pl file. Trying it out over here... yes, if I rename my file from .pl to .pod, then perldoc runs OK on it, without the =head1 element. Very interesting.	[reply]
Re^3: Mysterious crash of perldoc by hippo (Archbishop) on Mar 15, 2019 at 09:18 UTC
Good catch - the name is indeed significant. If I rename the file to have a `.pl` extension then I see this: `$ mv foo.pod foo.pl $ perldoc -T foo.pl No documentation found for "foo.pl". $ echo $? 1 $` [download] because the contents are now expected to be a perl script and there's nothing in the POD there which refers to "foo.pl". Adding a header with that text for reference satisfies this requirement. `$ cat foo.pl #!/usr/bin/perl -w use strict; =pod =head1 foo.pl My documentation. =cut $ perldoc -T foo.pl FOO(1) User Contributed Perl Documentation + FOO(1) foo.pl My documentation. perl v5.10.1 2019-03-15 + FOO(1) $ echo $? 0 $` [download]	[reply] [d/l] [select]
Re^4: Mysterious crash of perldoc by pryrt (Abbot) on Mar 15, 2019 at 16:10 UTC
hippo, I don't think it's mentioning "foo.pl" which solved the problem when in a .pl extension: cmd.exe>type foo.pl && perldoc foo.pl #!/usr/bin/perl -w use strict; =item foo.pl My Documentation =cut No documentation found for "foo.pl". cmd.exe>type foo.pl && perldoc foo.pl #!/usr/bin/perl -w use strict; =head1 foo.pl My Documentation =cut foo.pl My Documentation cmd.exe>type foo.pl && perldoc foo.pl #!/usr/bin/perl -w use strict; =begin foo.pl My Documentation =cut No documentation found for "foo.pl". cmd.exe>type foo.pl && perldoc foo.pl #!/usr/bin/perl -w use strict; =head1 SomethingElse My Documentation =cut SomethingElse My Documentation cmd.exe>type foo.pl && perldoc foo.pl #!/usr/bin/perl -w use strict; =head4 SomethingElse My Documentation =cut SomethingElse My Documentation cmd.exe>type foo.pod && perldoc foo.pod #!/usr/bin/perl -w use strict; =pod My Documentation =cut My Documentation [download] Per that experiment: inside a .pl, it's solely a matter of whether there was a `=head`: it doesn't matter whether it's a `=head1` or `=head4`; if a .pl has a head, then perldoc is fine, whether or not it mentions the name of the .pl. Meanwhile, the .pod is fine with just `=pod`, and doesn't need a mention of `=head` to be properly parsed/rendered by perldoc.	[reply] [d/l] [select]