|
NAMEHTML::Template::Compiled - Template System Compiles HTML::Template files to Perl codeSYNOPSISuse HTML::Template::Compiled; # recommended options: # case_sensitive => 1 # search_path_on_include => 1 # use_query => 0 # default_escape => 'HTML' # <-- HIGHLY RECOMMENDED # note that the following # use HTML::Template::Compiled speed => 1 # is deprecated (can be problematic under persistent environments) # or for the biggest compatibility with HTML::Template # case_sensitive => 0 # search_path_on_include => 0 # use_query => 1 # note that the following # use HTML::Template::Compiled compatible => 1; # is deprecated (can be problematic under persistent environments) # or use HTML::Template::Compiled::Classic my $htc = HTML::Template::Compiled->new( filename => 'test.tmpl', case_sensitive => 1, default_escape => 'HTML', ); $htc->param( BAND => $name, ALBUMS => [ { TITLE => $t1, YEAR => $y1 }, { TITLE => $t2, YEAR => $y2 }, ], ); print $htc->output; test.tmpl: Band: <TMPL_VAR BAND> <TMPL_LOOP ALBUMS> Title: <TMPL_VAR TITLE> (<TMPL_VAR YEAR>) </TMPL_LOOP> Or use different tag styles: Band: <%= BAND %> <%loop ALBUMS %> Title: <%= TITLE %> (<%= YEAR %>) <%/loop %> Band: [%= BAND %] [%loop ALBUMS %] Title: [%= TITLE %] ([%= YEAR %]) [%/loop %] DESCRIPTIONHTML::Template::Compiled is a template system which can be used for HTML::Template templates with almost the same API. It offers more flexible template delimiters, additional tags and features, and by compiling the template into perl code it can run significantly faster in persistent environments such as FastCGI or mod_perl.The goal is to offer more features for flexibility but keep the basic syntax as easy as it is. Features at a glance:
For a quick reference, see HTML::Template::Compiled::Reference. As the basic features work like in HTML::Template, please get familiar with its documentation before. HTML::Template::Compiled (HTC) does not implement all features of HTML::Template (see "COMPATIBILITY"), and it has got some additional features which are explained below: "ADDITIONAL FEATURES" See "BENCHMARKS" for some examples on the performance. Since it depends highly on the options used and on the template size there can be no general statement on its performance. You might want to use HTML::Template::Compiled::Lazy for CGI environments as it doesn't parse the template before calling output. But note that HTC::Lazy isn't much tested, and I don't use it myself, so there's a lack of experience. If you use it and have problems, please report. HTC will use a lot of memory because it keeps all template objects in memory. If you are on mod_perl, and have a lot of templates, you should preload them at server startup to be sure that it is in shared memory. At the moment HTC is not fully tested for keeping all data in shared memory (e.g. when a copy-on-write occurs), but it seems like it's behaving well. For preloading you can use HTML::Template::Compiled->preload($cache_dir). Generating code, writing it on disk and later eval() it can open security holes, for example if you have more users on the same machine that can access the same files (usually an http server running as 'www' or 'nobody'). See "SECURITY" for details what you can do to safe yourself. NOTE: If you don't need any of the additional features listed below and if you don't need the speed (in many cases it's probably not worth trading speed for memory), then you might be better off with just using HTML::Template. NOTE2: If you have any questions, bug reports, send them to me and not to Sam Tregar. This module is developed by me at the moment, independently from HTML::Template, although I try to get most of the tests from it passing for HTC. See "RESOURCES" for current information. FEATURES FROM HTML::TEMPLATE
ADDITIONAL FEATURESWhat can HTC do for you additionally to HTML::Template?
MISSING AND DIFFERENT FEATURESThere are some features of H::T that are missing or behaving different. I'll try to list them here.MISSING FEATURES
DIFFERENT FEATURES
Note: the following is deprecated: To be compatible in all of the above options all use: use HTML::Template::Compiled compatible => 1; If you don't care about these options you should use use HTML::Template::Compiled speed => 1; which is the default but depending on user wishes that might change. DEPRECATED
ESCAPINGLike in HTML::Template, you have "ESCAPE=HTML", "ESCAPE=URL" and "ESCAPE_JS". "ESCAPE=HTML" will only escape '"&<>. If you want to escape more, use "ESCAPE=HTML_ALL". Additionally you have "ESCAPE=DUMP", which by default will generate a Data::Dumper output.You can also chain different escapings, like "ESCAPE=DUMP|HTML". Additionally to ESCAPE=JS you have ESCAPE=IJSON which does not escape the single quote. INCLUDEAdditionally to<TMPL_INCLUDE NAME="file.htc"> you can do an include of a template variable: <TMPL_INCLUDE_VAR NAME="file_include_var"> $htc->param(file_include_var => "file.htc"); Using "INCLUDE VAR="..."" is deprecated. You can also include strings: template: inc: <%include_string foo %> code: $htc->param( foo => 'included=<%= bar%>', bar => 'real', ); output: inc: included=real Note that included strings are not cached and cannot include files or strings themselves. EXTENDED VARIABLE ACCESSWith HTC, you have more control over how you access your template parameters. An example:my %hash = ( SELF => '/path/to/script.pl', LANGUAGE => 'de', BAND => 'Bauhaus', ALBUMS => [ { NAME => 'Mask', SONGS => [ { NAME => 'Hair of the Dog' }, ... ], }, ], INFO => { BIOGRAPHY => '...', LINK => '...' }, NAME => "Cool script", ); Now in the TMPL_LOOP "ALBUMS" you would like to access the path to your script, stored in $hash{SELF}. in HTML::Template you have to set the option "global_vars", so you can access $hash{SELF} from everywhere. Unfortunately, now "NAME" is also global, which might not a problem in this simple example, but in a more complicated template this is impossible. With HTC, you wouldn't use "global_vars" here, but you can say: <TMPL_VAR .SELF> to access the root element, and you could even say ".INFO.BIOGRAPHY" or "ALBUMS[0].SONGS[0].NAME" (the latter has changed since version 0.79) RENDERING OBJECTSThis is still in development, so I might change the API here.Additionally to feeding a simple hash to HTC, you can feed it objects. To do method calls you can also use '.' in the template. my $htc = HTML::Template::Compiled->new( ... ); $htc->param( VAR => "blah", OBJECT => bless({...}, "Your::Class"), ); <TMPL_VAR NAME="OBJECT.fullname"> <TMPL_WITH OBJECT> Name: <TMPL_VAR fullname> </TMPL_WITH> "fullname" will call the fullname method of your Your::Class object. It's recommended to just use the default . value for methods and dereferencing. I might stop supporting that you can set the values for method calls by setting an option. Ideally I would like to have that behaviour changed only by inheriting. RUNNING PERL WITH TMPL_PERLYes, templating systems are for separating code and templates. But as it turned out to be implemented much easier than expressions i decided to implement it. But expressions are also available with the option "use_expressions".Note: If you have templates that can be edited by untrustworthy persons then you don't want them to include perl code. So, how do you use the perl-tag? First, you have to set the option "use_perl" to 1 when creating a template object. Important note: don't use "print" in the included code. Usually the template code is concatenated and returned to your perl script. To 'print' something out use __OUT__ 2**3; This will be turned into something like $OUT .= 2**3; # or print $fh 2**3; Important note 2: HTC does not parse Perl. if you use the classic tag-delimiters like this: <tmpl_perl if (__CURRENT__->count > 42) { > this will not work as it might seem. Use other delimiters instead: <%perl if (__CURRENT__->count > 42) { %> Example: <tmpl_loop list> <tmpl_perl unless (__INDEX__ % 3) { > </tr><tr> <tmpl_perl } > </tmpl_loop list> # takes the current position of the parameter # hash, key 'foo' and multiplies it with 3 <%perl __OUT__ __CURRENT__->{foo} * 3; %> List of special keywords inside a perl-tag:
INHERITANCEIt's possible since version 0.69 to inherit from HTML::Template::Compiled. It's just not documented, and internal method names might change in the near future. I'll try to fix the API and document which methods you can inherit.METHODS TO INHERIT
DEBUGGINGFor printing out the contents of all the parameters you can do:<TMPL_LOOP ALBUMS> Dump: <TMPL_VAR _ ESCAPE=DUMP|HTML> </TMPL_LOOP> The special name "_" gives you the current parameter and "ESCAPE=DUMP" will by default generate a Data::Dumper output of the current variable, in this case it will dump out the contents of every album in a loop. To correctly display that in html "|HTML" will escape html entities. TMPL_WITHIf you have a deep leveled hash you might not want to always write THE.FULL.PATH.TO.YOUR.VAR. Jump to your desired level once and then you need only one level. Compare:<TMPL_WITH DEEP.PATH.TO.HASH> <TMPL_VAR NAME>: <TMPL_VAR AGE> </TMPL_WITH> <TMPL_VAR DEEP.PATH.TO.HASH.NAME>: <TMPL_VAR DEEP.PATH.TO.HASH.AGE> Inside TMPL_WITH you can't reference parent nodes unless you're using global_vars. TMPL_LOOPThe special name "_" gives you the current parameter. In loops you can use it like this:<tmpl_loop foo> Current item: <tmpl_var _ > </tmpl_loop> Also you can give the current item an alias. See "ALIAS". The LOOP tag allows you to define a JOIN attribute: <tmpl_loop favourite_colors join=", "> <tmpl_var _ > </tmpl_loop> This will output something like "blue, pink, yellow". This is easier than doing: <tmpl_loop favourite_colors> <tmpl_unless __first__>, </tmpl_unless> <tmpl_var _ > </tmpl_loop> The "LOOP", "WHILE" and "EACH" tags allow you to define a BREAK attribute: <tmpl_loop bingo break="3"> <tmpl_var _ ><if __break__>\n</if></tmpl_loop> $htc->param(bingo => [qw(X 0 _ _ X 0 _ _ X)]); outputs X 0 _ _ X 0 _ _ X So specifying BREAK=3 sets __break__ to 1 every 3rd loop iteration. TMPL_LOOP expects an array reference, also if it is a method call. If you want to iterate with TMPL_LOOP over a list from a method call, set the attribute "context=list": <tmpl_loop object.list_method context=list> <tmpl_var _ > </tmpl_loop> TMPL_WHILEUseful for iterating, for example over database resultsets. The directive<tmpl_while resultset.fetchrow> <tmpl_var _.0> </tmpl_while> will work like: while (my $row = $resultset->fetchrow) { print $row->[0]; } So the special variable name _ is set to the current item returned by the iterator. You also can use "ALIAS" here. TMPL_EACHIterating over a hash. Internally it is not implemented as an each, so you can also sort the output:Sorted alphanumerically by default (since 0.93): <tmpl_each letters > <tmpl_var __key__ >:<tmpl_var __value__> </tmpl_each letters > Sorted numerically: <tmpl_each numbers sort=num > <tmpl_var __key__ >:<tmpl_var __value__> </tmpl_each numbers > Not sorted: <tmpl_each numbers sort=0 > <tmpl_var __key__ >:<tmpl_var __value__> </tmpl_each numbers > Sorted alphanumerically: <tmpl_each letters sort=alpha > <tmpl_var __key__ >:<tmpl_var __value__> </tmpl_each letters > You have to set the option "loop_context_vars" to true to use the special vars "__key__" and "__value__". If you want to iterate over a hash instead of a hashref (some methods might return plain hashes instead of references and TMPL_EACH expects a ref), then you can set "context=list": <tmpl_each object.hash_method context=list> <tmpl_var __key__ > </tmpl_each> Since 1.000_001 you can also define by which variable you want to sort. If you have a hash with hashes as values: $htc->param( letters => { 1 => { letter =>'b' }, 2 => { letter =>'a' }, 3 => { letter =>'c' }, }, ); <%each letters sort=alpha sortby="letter" %> <%set_var val value=__value__ %> <%= __key__ %> = <%= $val.letter %> <%/each%> SET_VARSince 0.96_002Sets a local variable to the value given in "value" or "expr" <tmpl_set foo expr=23> <tmpl_set name=bar expr=23> <tmpl_set boo value=var.boo> <tmpl_set oof expr="21*2"> <tmpl_var $foo> <tmpl_var $bar> ... "value=.." behaves like a variable name from the parameter stash. The variable name to set must match /[0-9a-z_]+/i You can refer to an alias via $alias or simply "alias". Note that the latter syntax is not recommended any more since it can conflict with parameters from the stash. If you want to use aliases in includes, you need to use the $alias syntax. USE_VARSdeprecated. Was added in 0.96_004 to make it possible to use aliases set with "alias=..." or "SET_VAR" in includes. Now you should rather use the <$alias> syntax.The following explanation is just there for history and will be removed some time in the future. For now it still works. Necessary if you want vars like SET_VAR and loop aliases from outside in includes. Before the first use in the include, add: <tmpl_use_vars foo,bar,boo > so that the compiler recognizes them as user defined vars and not parameters from the stash. This statement is valid until the end of the template so you cannot "overwrite" parameters of the stash locally. WRAPPERSince 0.97_005. Experimental. Please test.Needs option "loop_context_vars". Works similar to WRAPPER in Template-Toolkit. Is similar to TMPL_INCLUDE, just that the included wrapper is wrapped around the content. It can be used to avoid including head and foot separately. <tmpl_wrapper wrapper.html > content: some var: <tmpl_var foo > </tmpl_wrapper> In wrapper.html the special loop context var "__wrapper__" is used for the included content: wrapper.html: <some><layout> <tmpl_var __wrapped__ > </layout></some> Important notes: If you are using "out_fh" to print directly to a filehandle instead of returning to a string, this feature might not be useful, since it is appending the content inside of the wrapper to a string and prints it when it comes to the end of the wrapper tag. So if you are using "out_fh" to avoid generating long strings in memory, you should rather use TMPL_INCLUDE instead. Also you need perl 5.8 or higher to use it in combination with out_fh. TMPL_COMMENTFor debugging purposes you can temporarily comment out regions:Wanted: <tmpl_var wanted> <tmpl_comment outer> this won't be printed <tmpl_comment inner> <tmpl_var unwanted> </tmpl_comment inner> <tmpl_var unwanted> </tmpl_comment outer> $htc->param(unwanted => "no thanks", wanted => "we want this"); The output is (whitespaces stripped): Wanted: we want this HTC will ignore anything between COMMENT directives. This is useful for debugging, and also for documentation inside the template which should not be outputted. TMPL_NOPARSEAnything between<tmpl_noparse>...</tmpl_noparse> will not be recognized as template directives. Same syntax as TMPL_COMMENT. It will output the content, though. TMPL_VERBATIMAnything between<tmpl_verbatim>...</tmpl_verbatim> will not be recognized as template directives. Same syntax as "TMPL_NOPARSE", but it will be HTML-Escaped. This can be useful for debugging. TMPL_SWITCHThe SWITCH directive has the same syntax as VAR, IF etc. The CASE directive takes a simple string or a comma separated list of strings. Yes, without quotes. This will probably change! I just don't know yet how it should look like. Suggestions?With that directive you can do simple string comparisons. <tmpl_switch language>(or <tmpl_switch name=language>) <tmpl_case de>echt cool <tmpl_case en>very cool <tmpl_case es>superculo <tmpl_case fr,se>don't speak french or swedish <tmpl_case default>sorry, no translation for cool in language <%=language%> available <tmpl_case>(same as default) </tmpl_switch> It's also possible to specify the default with a list of other strings: <tmpl_case fr,default> Note that the default case should always be the last statement before the closing switch. OPTIONSAs you can cache the generated perl code in files, some of the options are fixed; that means for example if you set the option case_sensitive to 0 and the next time you call the same template with case_sensitive 1 then this will be ignored. The options below will be marked as (fixed).
METHODS
EXPORTNone.CACHINGYou create a template almost like in HTML::Template:my $t = HTML::Template::Compiled->new( path => 'templates', loop_context_vars => 1, filename => 'test.html', # for testing without cache comment out file_cache => 1, file_cache_dir => "cache", ); The next time you start your application and create a new template, HTC will read all generated perl files, and a call to the constructor like above won't parse the template, but just use the loaded code. If your template file has changed, though, then it will be parsed again. You can set the expire time of a template by passing the option expire_time => $seconds Note that HTML::Template::Compiled->ExpireTime($seconds); C<$HTML::Template::Compiled::NEW_CHECK> are deprecated since they change a global variable which is then visible in the whole process, so in persistent environments other apps might be affected. So an expire time of 600 seconds (default) will check after 10 minutes if the tmpl file was modified. Set it to a very high value will then ignore any changes, until you delete the generated code. For development you should set it to 0, for a pre-production server you can set it to 60 seconds, for example. It can make quite a difference. PLUGINSAt the moment you can use and write plugins for the "ESCAPE" attribute. See HTML::Template::Compiled::Plugin::XMLEscape for an example how to use it; and have a look at the source code if you want to know how to write a plugin yourself.Using Plugins: my $htc = HTML::Template::Compiled->new( ... plugin => ['HTML::Template::Compiled::Foo::Bar'], # oor shorter: plugin => ['::Foo::Bar'], ); LAZY LOADINGLet's say you're in a CGI environment and have a lot of includes in your template, but only few of them are actually used. HTML::Template::Compiled will (as HTML::Template does) parse all of your includes at once. Just like the "use" function does in perl. To get a behaviour like require, use HTML::Template::Compiled::Lazy.TODOassociate, methods with simple parameters, expressions, pluggable, ...IMPLEMENTATIONHTC generates a perl subroutine out of every template. Each included template is a subroutine for itself. You can look at the generated code by activating file caching and looking into the cache directory. When you call "output()", the subroutine is called. The subroutine either creates a string and adds each template text or the results of the tags to the string, or it prints it directly to a filehandle. Because of the implementation you have to know at creation time of the module if you want to get a string back or if you want to print to a filehandle.SECURITYHTML::Template::Compiled uses basically the same file caching model as, for example, Template- Toolkit does: The compiled Perl code is written to disk and later reread via "do" or by reading the file and "eval" the content.If you are sharing a read/write environment with untrusted users (for example on a machine with a webserver, like many webhosters offer, and all scripts are running as the same httpd user), realize that there is possibility of modifying the Perl code that is cached and then executed. The best solution is to not be in such an environment! In this case it is the safest option to generate your compiled templates on a local machine and just put the compiled templates onto the server, with no write access for the http server. Set the "expire_time" option to a high value so that HTC never attempts to check the template timestamp to force a regenerating of the code. If you are alone on the machine, but you are running under taint mode (see perlsec) then you have to explicitly set the $UNTAINT variable to 1. HTC will then untaint the code for you and treat it as if it were safe (it hopefully is =). PRECOMPILEI think there is no way to provide an easy function for precompiling, because every template can have different options. If you have all your templates with the same options, then you can use the precompile class method. It works like this:HTML::Template::Compiled->precompile( # usual options like path, default_escape, global_vars, file_cache_dir, ... filenames => [ list of template-filenames ], ); This will then pre-compile all templates into file_cache_dir. Now you would just put this directory onto the server, and it doesn't need any write-permissions, as it will be never changed (until you update it because templates have changed). BENCHMARKSThe options "case_sensitive", "loop_context_vars" and "global_vars" can have the biggest influence on speed.Setting case_sensitive to 1, loop_context_vars to 0 and global_vars to 0 saves time. On the other hand, compared to HTML::Template, you have a large speed gain under mod_perl if you use case_sensitive = 1, loop_context_vars = 0, With CGI HTC is slower. See the "examples/bench.pl" contained in this distribution. Here are some examples from the benchmark script. I'm showing only Template::AutoFilter, Template::HTML, HTML::Template and HTC. These four modules allow you to set automatic HTML escaping ('filter') for all variables. loop_context_vars 1 global_vars 0 case_sensitive 1 default_escape HTML (respectively Template::AutoFilter and Template::HTML) ht: HTML::Template 2.10 htc: HTML::Template::Compiled 0.95 ttaf: Template::AutoFilter 0.112350 with Template 2.22 tth: Template::HTML 0.02 with Template 2.22 First test is with the test.(htc|tt) from the examples directory, about 900 bytes. Test without file cache and without memory cache. all_ht: 1 wallclock secs ( 0.40 usr + 0.00 sys = 0.40 CPU) @ 250.00/s (n=100) all_htc: 1 wallclock secs ( 1.74 usr + 0.01 sys = 1.75 CPU) @ 57.14/s (n=100) all_ttaf_new_object: 1 wallclock secs ( 1.69 usr + 0.01 sys = 1.70 CPU) @ 58.82/s (n=100) all_tth_new_object: 1 wallclock secs ( 1.44 usr + 0.00 sys = 1.44 CPU) @ 69.44/s (n=100) With file cache: all_ht: 1 wallclock secs ( 1.03 usr + 0.01 sys = 1.04 CPU) @ 379.81/s (n=395) all_htc: 1 wallclock secs ( 1.07 usr + 0.00 sys = 1.07 CPU) @ 260.75/s (n=279) all_ttaf_new_object: 1 wallclock secs ( 1.07 usr + 0.04 sys = 1.11 CPU) @ 251.35/s (n=279) all_tth_new_object: 1 wallclock secs ( 1.01 usr + 0.04 sys = 1.05 CPU) @ 227.62/s (n=239) With memory cache: all_ht: 1 wallclock secs ( 1.04 usr + 0.00 sys = 1.04 CPU) @ 461.54/s (n=480) all_htc: 1 wallclock secs ( 1.05 usr + 0.01 sys = 1.06 CPU) @ 3168.87/s (n=3359) process_ttaf: 1 wallclock secs ( 1.04 usr + 0.00 sys = 1.04 CPU) @ 679.81/s (n=707) process_tth: 1 wallclock secs ( 1.05 usr + 0.00 sys = 1.05 CPU) @ 609.52/s (n=640) Now I'm using a template with about 18Kb by multiplying the example template 20 times. You can see that everything is running slower but some run more slower than others. Test without file cache and without memory cache. all_ht: 8 wallclock secs ( 7.57 usr + 0.04 sys = 7.61 CPU) @ 13.14/s (n=100) all_htc: 32 wallclock secs (32.08 usr + 0.06 sys = 32.14 CPU) @ 3.11/s (n=100) all_ttaf_new_object: 36 wallclock secs (36.21 usr + 0.04 sys = 36.25 CPU) @ 2.76/s (n=100) all_tth_new_object: 29 wallclock secs (28.92 usr + 0.05 sys = 28.97 CPU) @ 3.45/s (n=100) With file cache: all_ht: 8 wallclock secs ( 7.22 usr + 0.00 sys = 7.22 CPU) @ 13.85/s (n=100) all_htc: 5 wallclock secs ( 5.32 usr + 0.00 sys = 5.32 CPU) @ 18.80/s (n=100) all_ttaf_new_object: 8 wallclock secs ( 7.59 usr + 0.15 sys = 7.74 CPU) @ 12.92/s (n=100) all_tth_new_object: 9 wallclock secs ( 8.74 usr + 0.19 sys = 8.93 CPU) @ 11.20/s (n=100) With memory cache: all_ht: 1 wallclock secs ( 1.04 usr + 0.01 sys = 1.05 CPU) @ 15.24/s (n=16) all_htc: 1 wallclock secs ( 1.12 usr + 0.00 sys = 1.12 CPU) @ 272.32/s (n=305) process_ttaf: 1 wallclock secs ( 1.07 usr + 0.00 sys = 1.07 CPU) @ 39.25/s (n=42) process_tth: 1 wallclock secs ( 1.05 usr + 0.00 sys = 1.05 CPU) @ 34.29/s (n=36) So the performance difference highly depends on the size of the template and on the various options. You can see that using the 900byte template HTC is slower with file cache than HTML::Template, but with the 18Kb template it's faster. EXAMPLESSee "objects.html" in examples (and "examples/objects.pl") for an example how to feed objects to HTC.BUGSProbably many bugs I don't know yet =)Use the bugtracking system to report a bug: http://rt.cpan.org/NoAuth/Bugs.html?Dist=HTML-Template-Compiled Why another Template System?You might ask why I implement yet another templating system. There are so many to choose from. Well, there are several reasons.I like the syntax of HTML::Template *because* it is very restricted. It's also easy to use (template syntax and API). However, there are some things I miss I try to implement here. I think while HTML::Template is quite good, the implementation can be made more efficient (and still pure Perl). That's what I'm trying to achieve. I use it in my web applications, so I first write it for myself =) If I can efficiently use it, it was worth it. RESOURCESSee http://htcompiled.sf.net/ for svn access.SEE ALSOHTML::TemplateHTML::Template::JIT Template - Toolkit http://www.tinita.de/projects/perl/ AUTHORTina MuellerCREDITSSam Tregar big thanks for ideas and letting me use his HTML::Template test suiteBjoern Kriews for original idea and contributions Special Thanks to Sascha Kiefer - he finds all the bugs! Ronnie Neumann, Martin Fabiani, Kai Sengpiel, Jan Willamowius, Justin Day, Steffen Winkler, Henrik Tougaard for ideas, beta-testing and patches <http://www.perlmonks.org/> and http://www.perl-community.de/> for everyday learning Corion, Limbic~Region, tye, runrig and others from perlmonks.org COPYRIGHT AND LICENSECopyright (C) 2005-2012 by Tina MuellerThis library is free software; you can redistribute it and/or modify it under the same terms as Perl itself, either Perl version 5.8.3 or, at your option, any later version of Perl 5 you may have available.
Visit the GSP FreeBSD Man Page Interface. |