What is the role of the BEGIN block in Perl?

Question

I know that the BEGIN block is compiled and executed before the main body of a Perl program. If you\'re not sure of that just try running the command perl -cw over this:

Answer 1

Have you tried swapping out the BEGIN{} block for an INIT{} block? That's the standard approach for things like modperl which use the "compile-once, run-many" model, as you need to initialize things anew on each separate run, not just once during the compile.

But I have to ask why it's all in special block anyway. Why don't you just make some sort of prepare_db_connection() function, and then call it as you need to when the program starts up?

Something that won't work in a BEGIN{} will also have the same problem if it's main-line code in a module file that gets used. That's another possible reason to use an INIT{} block.

I've also seen deadly-embrace problems of mutual recursion that have to be unravelled using something like an require instead of use, or an INIT{} instead of a BEGIN{}. But that's pretty rare.

Consider this program:

% cat sto-INIT-eg
#!/usr/bin/perl -l
print               "    PRINT: main running";
die                 "    DIE:   main dying\n";
die                 "DIE XXX /* NOTREACHED */";
END         { print "1st END:   done running"    }
CHECK       { print "1st CHECK: done compiling"  }
INIT        { print "1st INIT:  started running" }
END         { print "2nd END:   done running"    }
BEGIN       { print "1st BEGIN: still compiling" }
INIT        { print "2nd INIT:  started running" }
BEGIN       { print "2nd BEGIN: still compiling" }
CHECK       { print "2nd CHECK: done compiling"  }
END         { print "3rd END:   done running"    }

When compiled only, it produces:

% perl -c sto-INIT-eg 
1st BEGIN: still compiling
2nd BEGIN: still compiling
2nd CHECK: done compiling
1st CHECK: done compiling
sto-INIT-eg syntax OK

While when compiled and executed, it produces this:

% perl sto-INIT-eg 
1st BEGIN: still compiling
2nd BEGIN: still compiling
2nd CHECK: done compiling
1st CHECK: done compiling
1st INIT:  started running
2nd INIT:  started running
    PRINT: main running
    DIE:   main dying
3rd END:   done running
2nd END:   done running
1st END:   done running

And the shell reports an exit of 255, per the die.

You should be able to arrange to have the connection happen when you need it to, even if a BEGIN{} proves too early.

Hm, just remembered. There's no chance you're doing something with DATA in a BEGIN{}, is there? That's not set up till the interpreter runs; it's not open to the compiler.

Answer 2

While the other answers are true, I find it also worth to mention the use of BEGIN and END blocks when using the -n or -p switches to Perl.

From http://perldoc.perl.org/perlmod.html

When you use the -n and -p switches to Perl, BEGIN and END work just as they do in awk, as a degenerate case.

For those unfamiliar with the -n switch, it tells Perl to wrap the program with:

while (<>) {
    ...  # your program goes here
}

http://perldoc.perl.org/perlrun.html#Command-Switches if you're interested about more specific information about Perl switches.

As an example to demonstrate the use of BEGIN with the -n switch, this Perl one-liner enumerates the lines of the ls command:

ls | perl -ne 'BEGIN{$i = 1} print "$i: $_"; $i += 1;'

In this case, the BEGIN-block is used to initiate the variable $i by setting it to 1 before processing the lines of ls. This example will output something like:

1: foo.txt
2: bar.txt
3: program.pl
4: config.xml

Answer 3

While BEGIN and END blocks can be used as you describe, the typical usage is to make changes that affect the subsequent compilation.

For example, the use Module qw/a b c/; statement actually means:

BEGIN {
   require Module;
   Module->import(qw/a b c/);
}

similarly, the subroutine declaration sub name {...} is actually:

BEGIN {
   *name = sub {...};
}

Since these blocks are run at compile time, all lines that are compiled after a block has run will use the new definitions that the BEGIN blocks made. This is how you can call subroutines without parenthesis, or how various modules "change the way the world works".

END blocks can be used to clean up changes that the BEGIN blocks have made but it is more common to use objects with a DESTROY method.

If the state that you are trying to clean up is a DBI connection, doing that in an END block is fine. I would not create the connection in a BEGIN block though for several reasons. Usually there is no need for the connection to be available at compile time. Performing actions like connecting to a database at compile time will drastically slow down any editor you use that has syntax checking (because that runs perl -c).