What do I do after printing HTML in my Perl CGI script?

You should always print out "\n\n" at the end of your output to tell the webserver the output is finished. Apache may do this for you on successful script termination If your script is finished, you should technically call "exit" with the appropriate exit status-- zero for success, nonzero for errors. The webserver inspects the exit status and renders the appropriate page (error code 500 is typical if the exit status shows anything other than success).

If you don't specify a "return" value or call exit directly, Perl (in this case) will assume successful termination and the webserver will treat your CGI script the same as if you called "exit(0) This is all described in the CGI specification (RFC 3875 is current, IIRC).

You should always print out "\n\n" at the end of your output to tell the webserver the output is finished. Apache may do this for you on successful script termination. If your script is finished, you should technically call "exit" with the appropriate exit status-- zero for success, nonzero for errors.

The webserver inspects the exit status and renders the appropriate page (error code 500 is typical if the exit status shows anything other than success). If you don't specify a "return" value or call exit directly, Perl (in this case) will assume successful termination and the webserver will treat your CGI script the same as if you called "exit(0)". This is all described in the CGI specification (RFC 3875 is current, IIRC).

1 You don't need to print a double newline at the end of the output. That's only to separate the header from the body. – brian d foy Nov 2 '09 at 19:41.

I guess this is more a question about coding style than functionality. If you have a simple, straightforward program, with no branching, there is little reason to mark the termination of the program by anything special: return is not going to return anything that anybody can use, since your program ends here exit is just going to exit with status 0, which would happen naturally anyway However, if the structure is more complex, I would advise to mark the termination point by something specific, to signal to someone who reads your code that, for that defined set of conditions, there is nothing to take into account there anymore. I would use exit rather than return, for the simple reason that return can be mistaken for the end of a sub, whereas exit very specifically states that the program terminates at this point.

This was a simplified example. Let's say you have a bunch of tests and you are redirecting based on the result of the test. Is it enough to see print "Location: foo.Pl\n\n"; and know that's the end of the script in that particular test?

I can elaborate in the question if this isn't clear. – cowgod Apr 8 '09 at 22:56 Please elaborate a bit on the structure of your code. If you have a bunch of different cases, where you can terminate before the physical end of the file, IMO you should include some termination marker, preferably exit... – Varkhan Apr 8 '09 at 23:10 Question updated.

– cowgod Apr 8 '09 at 23:25 Answer updated ;) – Varkhan Apr 8 '09 at 23:59.

No, it doesn't matter. I always let the script die by itself instead of 'return;' or 'exit;' since there's no need for either of those statements (in the end of a perl document that is) and it's the same thing as 'exit;' or 'exit 0;'.

I would recommend return instead of exit so that if you switch to CGI::Fast you can just turn it into a sub.

It makes sense that you don't necessarily have to return or exit if it is a stand-alone thing. But what if this snippet is from within a function? Would it still apply?

Would return or exit be preferred for some reason? Is it still just styling?

To answer your "updated" question: In my current application, I use common methods to do something like this: # UI. Pm package UI; sub top { print "$_0"; } sub bottom { print "Welcome to my page! "; UI::bottom(); If you're feeling adventurous, you could hook BEGIN and END to do this automatically, but I wouldn't - I think it'd be too much fiddling around for a fairly minor benefit.

This isn't how I'd do it now, if I had to do it all over: I'd rely more on some sort of middle layer such as Catalyst, which would allow me to move up quickly to mod_perl or back to CGI. Or even better, write my application from the ground-up to use more AJAX - that way, most of my "actions" are carried out by really small Perl scripts which just process the input and respond back to the Javascript application in text/plain or text/json.

I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.