develooper Front page | perl.perl5.porters | Postings from April 2003

Re: [PATCH 5.8.0 UTIL] Fix installhtml for splitting and PM/POD conflicts

Thread Previous | Thread Next
From:
Steve Hay
Date:
April 2, 2003 02:37
Subject:
Re: [PATCH 5.8.0 UTIL] Fix installhtml for splitting and PM/POD conflicts
Message ID:
3E8ABC85.5060807@uk.radan.com
Rafael Garcia-Suarez wrote:

>Thanks, applied as change #19128 to the development sources
>of perl. The actual patch I applied is copied below, so you can
>know what's the current state of installhtml -- you appear to be
>the only one to propose a patch to it since 5.8.0 was released.
>(If you want to grab the dev. version of perl, see the perlhack manpage)
>
>I notice that the --splithead option, used by default for
>perlipc.pod, doesn't appear to work correctly. Are you inclined
>to take a look at it ? (it produces a perlipc/0.html file when
>I do "make install.html").
>  
>
I've had a look at the --splithead option and come up with the patch 
attached.  (The diff is against perl-current, after #19128 was applied.)

The changes to the loop over the @splithead array are somewhat like the 
changes made in #19128 to the create_index() function, namely:

1) The /NAME=/ pattern is corrected so that it does match.  This means 
that the "index" page being created does indeed get chopped after the 
end of the index.

2) The HREF pattern match is made case-insensitive so it now matches too.

3) A new $pod variable is introduced as before, so that the links 
created are relative rather than absolute.

Finally, the htmlize() function is corrected.  It previously always 
passed "0" as the first argument to htmlify() [!!!] -- hence the 
"0.html" file that was being generated.

I've also changed it to use anchorify() rather than htmlify().  This is 
because the links written into the "index" page by pod2html() are 
generated by anchorify(), so the names must match in order for the links 
to work.  (Otherwise, for example, the perlipc.html "index" page will 
have a link to "see_also.html", whereas the filename chosen by htmlize() 
would be "see also.html" so the link is broken.)

I've also inserted some other substitutions into the name returned by 
htmlize() after the call to anchorify() because the name returned is to 
be used as a filename, hence must not contain any invalid filename 
characters.  For example, the perlipc manpage contains a "=head1" 
section named "Sockets: Client/Server Communication" -- we must remove 
the ":" and "/" characters before this can make a valid filename (on 
Windows, at least).

Are there any other characters that would be invalid in filenames on 
other OS's?  Is there a generic "filename-cleaning-up" routine anywhere? 
 (I couldn't see one in the File::Spec module.)

This solution is not perfect since the links in the "index" page do not 
have the additional substitutions applied to them.  Thus, in the above 
example, the link would be 
"perlipc/sockets:_client/server_communication.html" (only anchorified), 
whereas the file would be 
"perlipc/sockets__client_server_communication.html" (anchorified and 
filenameified).  Perhaps the additional substitutions should be applied 
within anchorify() itself?  However, that seems to be going beyond what 
that function sounds like it is going to do?

Please copy any replies to me -- I'm not on p5p.

Steve


Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About