Because BEGIN blocks are executed ASAP ( perlmod ), i use them to change @INC to allow me to load local modules :

  BEGIN {
  unshift @INC, "$ENV{HOME}/Desktop/CODE/lib"; ## include local lib
};
[download]

I am sure there are better examples out there though!

a my ($b, $c)
[download]

use A qw/a/;
a my ($b, $c);
[download]

The point is that Exporter->import defines a (probably via some clever version of eval 'sub ' . caller . '::' . $to_be_imported *) at compile time.

For an even subtler example of the nastiness that can occur, note that

my ( $b, $c );
a $b, $c;
[download]

$b->a($c)
[download]

* At least, I think that that's what happens; I got tired reading the Exporter source and didn't find out for sure. :-)

Prior to 5.10:

>perl -wMstrict -le
"S();
 S();
 {
   my $s = 'hiya';
   sub S { print $s++ }
   }
 S();
"
0
1
hiya

>perl -wMstrict -le
"S();
 S();
 BEGIN {
   my $s = 'hiya';
   sub S { print $s++ }
   }
 S();
"
hiya
hiyb
hiyc
[download]

>perl -wMstrict -lE
"S();
 S();
 sub S { state $s = 'hiya';  print $s++ }
 S();
"
hiya
hiyb
hiyc
[download]

The Poor Man's Grep: for use on Windows when you have Perl but not grep(1).

perl -nle "BEGIN{@ARGV=map{glob}@ARGV}/PATTERN/&&print" <files> ...
[download]

Replace PATTERN with the pattern you want to find.

Here, the BEGIN{} is used to convert any wildcards in the <files> into real file names.

The poor man's grep on Windows is findstr.

Or grep, or ack (designed as a replacement for 99% of the uses of grep).

package foo;
  BEGIN{
        $text = "Hello\n";
        }
sub subroutine {print $text} return 1;
[download]

require foo;
foo::subroutine();

#will print

Hello
[download]

• it is run early when your code is compiled (even before the rest of the file is parsed).
• you can use multiple BEGIN{} in the package and Perl will execute them by order of encounter.

1. You mean just BEGIN, not sub BEGIN. You're also missing a semicolon after package foo.
2. You should be naming your package files with extension .pm, not .pl. You also don't need to specify the extension when require- or use-ing.
3. You define subroutine in package foo, but try to use the subroutine from package1.
4. The biggest one: The behaviour you describe has nothing to do with BEGIN. It works just the same if you remove the BEGIN {} block.

UPDATE: AnomalousMonk points out (indirectly) that my point (4) is “only just” correct—the very early initialisation provided by BEGIN {} can certainly be useful if you might call a subroutine before some variables in it would be initialised by the normal flow of code.

Thanks for the tips, I have taken due action, and your clarification is appreciated, as for note number 4 , I was seeking simplicity by showing a behavior that is relatively easier to correlate with and that is general, What I have presented has to do more with Packages, just to show one side of the many places BEGIN{} can come in handy and it just shows where BEGIN{} block can feature in a Package...
Excellence is an Endeavor of Persistence. Chance Favors a Prepared Mind

Remember that use statements are implicitly emBEGINned - they're evaluated as soon as perl understands that they're there. So BEGIN blocks are actually evaluated not just when use is used, but before any other (non-BEGIN) code executes at all.

I've written a web application which uses BEGIN {} blocks to set up signal handlers for die()/warn() calls to do various site-specific stuff with them (like e-mailing the errors to the system admin so he knows there's problem afoot, and silencing warnings on the production site but making them fatal otherwise).

For example some settings for a connection to a database:

BEGIN {
  $ENV{NLS_LANG} = 'GERMAN';
  $ENV{NLS_DATE_FORMAT} = 'YYYY-MM-DD';
  $ENV{NLS_TIMESTAMP_FORMAT} = 'YYYY-MM-DD HH24:MI:SS';
}

use DBI;
my $dbh = DBI->connect('dbi:Oracle:db', 'user', 'pw');
[download]