First, you don't need sub there. Second, you don't need die or exit. Third, you want to run it with -c on the command line.

I think. I didn't actually test any of that... :-)

Update: Ok, I've tested it now. The code:

package Dependencies;

CHECK {
    print $_, $/ for values %INC;
}
1;
[download]

$ perl -MDependencies -c ./test.pl
/usr/lib/perl5/5.8.0/warnings/register.pm
/usr/lib/perl5/5.8.0/Carp.pm
Dependencies.pm
/usr/lib/perl5/5.8.0/vars.pm
/usr/lib/perl5/5.8.0/strict.pm
/usr/lib/perl5/5.8.0/Exporter.pm
/usr/lib/perl5/5.8.0/constant.pm
/usr/lib/perl5/5.8.0/warnings.pm
/usr/lib/perl5/5.8.0/CGI/Util.pm
/usr/lib/perl5/5.8.0/overload.pm
/usr/lib/perl5/5.8.0/CGI.pm
./test.pl syntax OK
[download]

-sauoq
"My two cents aren't worth a dime.";

you don't need sub there

I know, but I always do with BEGIN/INIT/CHECK/END these days.

Basically, I find the discrepancy between not having to use sub with those, but having to with TIEHASH/FETCH/STORE etc. inconsistant, and one thathad me taering my hair out for a while a couple of months back, so now I just avoid the inconsistancy. Call it an indulgance :)

I hadn't thought of combining the module with -c, that works really nicely++.

If you reverse the order of the switches you can almost read it as "perl check dependancies in test.pl", which works as a nice syntax reminder.

(I was going to use that new monic word, but I think I better stay clear of that:)

---

Examine what is said, not who speaks.
"Efficiency is intelligent laziness." -David Dunham
"When I'm working on a problem, I never think about beauty. I think only how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong." -Richard Buckminster Fuller

Call it an indulgance :)

I call it "confusing" because, well, it confuses me. :-)

Afterall, they aren't really subs, right? You can have more than one BEGIN (et al) block without concern for redefining previous ones. And, my $arg = shift; will shift off @ARGV rather than @_ as you would expect in a sub. Heck, you can't even explicitly call it!¹ And in those ways, they differ significantly from TIE* and family.

Frankly, and maybe I shouldn't admit this, I was surprised putting sub in front even worked. I always think of BEGIN, INIT, CHECK, and END as "special blocks" in a category of their own. I think I've been led that way by the documentation which uses the term "block" to describe them.

1. And trying to opened up a real can of worms. Apparently, even

sub main::BEGIN { print "X\n" }
[download]

is treated as a BEGIN block. You can jump through hoops to get a sub called BEGIN if you try:

*main::BEGIN = sub { print "X\n" };
&BEGIN;
[download]

but try

*main::BEGIN = sub { print "X\n" };
BEGIN();
[download]

Prototype mismatch? Ok, so put the prototype in...

*main::BEGIN = sub () { print "X\n" };
BEGIN();
[download]

That clears the complaint up just fine but our sub is never called. And while we are trying dumb things, take a look at this:

 
perl -e 'BEGIN'    # Syntax error. 
perl -e 'BEGIN;    # No error.
perl -e 'BEGIN()'  # Syntax error.
perl -e 'BEGIN();' # No error.
[download]

Blech! Blech! BLECH!

After all this, I'm inclined to think that sub BEGIN should be treated as an error if not a regular subroutine. (Of course, given the current state of affairs, we couldn't exactly start treating it as a regular subroutine now, could we? So I think it should be an error.)

-sauoq
"My two cents aren't worth a dime.";