But look at perlsub for the section on overriding built-in global functions. (You can do this per package or for all packages at once.)

Alternately you can look at perltie and create yourself a tied filehandle that you select before calling their code.

Personally rather than making this work as they want, I would select a tied filehandle that would take print's and cough and die with an informative error. Then people could still print to STDERR for debugging output.

How about overloading it in a more informative way? Perhaps you could overload print() with something like this (untested):



sub print {
  my $string = join '', @_;
  if ($string =~ /^(Content-type:)/) {
    CORE::print $string;
  }
  else {
    CORE::print "Content-type: text/html\n\n";
    die "You used print() rather than returning a string, you naughty 
+person";
  }
}
[download]

Something I DON'T know, however... would one need to prototype this overloaded print() to assure that it would work when used without parenthases, or is that taken care of becuase the built-in print() is already prototyped? You'd probably want to be sure beore doing it this way.

Alan "Hot Pastrami" Bellows

Then you would mess up someone who had inserted:

  print STDERR "Called node 'foo'\n";
[download]

as a debugging aid. (The messsage should show up in your webserver's logs.) The following (untested) code is much nicer:

package noprint;
use Carp;

sub PRINT {
  my $msg = Carp::longmess("You must return rather than print");
  print "Content-type: text/plain\n\n$msg";
  die $msg;
}

*PRINTF = *PRINT;

sub TIEHANDLE {
  return bless ({}, shift);
}
[download]

and elsewhere in the code:

tie(*NOPRINT, 'noprint');
select(NOPRINT);
# time passes while the page is built.
# Before spitting out the final page:
select(STDOUT);
[download]

That catches the newbie error. Without the potential for headaches that overriding print causes.

1. I don't know much about the Everything Engine, but I wonder if it is possible to simply output the content-type header at the beginning of the program, before the programmer's code is called.

2. I would want to educate the users not to make this mistake. Of course, that can be difficult, because every new user may need to be educated about this issue. That can end up being more work than just fixing the problem. :)

3. Overload the print function. I'm not sure offhand whether print is in the list of built-in functions that can be overloaded. Someone else can address this one. :)

4. Tie the output filehandle. Tying a filehandle other than STDOUT and selecting it would be fine, except what if a programmer prints explicitly to STDOUT? (e.g. print STDOUT "hello $USER->{title}")
So, this example that I wrote ties STDOUT. Of course, when tying STDOUT, you have to untie STDOUT before printing to it for real. It may not be the cleanest approach, but it does work.

#!/usr/local/bin/perl -w

use strict;

package DelayPrint;

sub TIEHANDLE {
    my $var = '';
    bless \$var, shift;
}

sub PRINT {
    my $ref = shift;
    $$ref .= join( (defined $, ? $, : ''), @_) . (defined $\ ? $\ : ''
+);
}

sub PRINTF {
    my $ref = shift;
    my $fmt = shift;
    $$ref .= sprintf($fmt, @_);
}

# flush: an additional function that returns the contents of the buffe
+r
# called via the object returned by tie()
sub flush {
    my $ref = shift;
    my $text = $$ref;
    $$ref = '';
    return $text;
}

package main;

my $fh = tie *STDOUT, 'DelayPrint';     # tie STDOUT

print "Hello world\n";                  # print through the tied fileh
+andle

my $text = $fh->flush();                # get the text that was printe
+d

undef $fh;                              # erase the reference,
untie *STDOUT;                          # untie the filehandle

print $text;                            # print the text for real
[download]

-- Randal L. Schwartz, Perl hacker

Slow down, cowboy! If you're thinking of skipping all of this concatenation rigamarole and just printing directly to the browser, stop. Remember, you're writing a component that has to be evaluated in the context of other components. No one knows what that's going to be until it actually happens. Take a deep breath, type 'my $str;', and you'll save yourself the time of wondering why your web browser seems to break.

It's really a behavioral issue. We can correct this with a filehandle tied to a scalar in the normal parsing mode. Every time evalCode returns, we just have to check for a chunk of CONTAINED_STUFF in the scalar, and put it in the right place. But in compiled mode, there's no good and clean way of doing that. (Mixing in calls to $tied_fh->get_and_clear() does not qualify as clean.)

I say, use the stick and not the carrot!

yeah -- about how many perl hackers read the manuals before trying their kung-fu out? ;)

The biggest problem is the context/header problem, even if it kicks out a backend error, rather than prepending to the return string, it's better than getting a dialog box which asks you where you want to save file "index.pl"...

Of course, that might be a good lesson in using the displaytype=edit param via the URL...

--nate

The former will actually cause problems with some browsers, because printing to STDOUT prints "hello world" before the content-type header.

I'd like to know some more about this problem. Can you show me some code that breaks on certain browsers?

As far as I can see, if you have code that does:

print "Content-type: text/html\n\n";

# and then later in the script...

print "<h1>Some title</h1>\n";
[download]

Then the second print statement should always display its output after the first. If that's not true, then I'd call that a bug.

There is a similar problem, where you have code like this:

print "Content-type: text/html\n\n";
print "<h1>Header</h1>\n";

# some code that generates an runtime error
[download]

In this case, because STDOUT is buffered by default and STDERR isn't, it is possible that the errors will be sent to the client before the header, causing an "invalid headers" error. The solution to this is to set $| to a true value to unbuffer STDOUT (or course, you'll still need to fix the bug that causes the error!).

"Perl makes the fun jobs fun
and the boring jobs bearable" - me

This is also in response to chipmunk's comment.

E* creates the entire page before it prints any output to STDOUT -- cookies are set in the header (along with the content-type), and developers need to be able to manipulate cookies on the current page. This is, of course, what causes the "print" bug -- which I'm hoping to curb.

thanks,

--nate