in reply to Re: Finding dependancies of a script
in thread Finding dependancies of a script

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;
And a test run (on a test script that consisted of a single line, "use CGI;"):
$ 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

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

Replies are listed 'Best First'.
Re: Re: Re: Finding dependancies of a script
by BrowserUk (Patriarch) on Jul 25, 2003 at 22:22 UTC

    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" }
      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;
      but try
      *main::BEGIN = sub { print "X\n" }; BEGIN();
      Prototype mismatch? Ok, so put the prototype in...
      *main::BEGIN = sub () { print "X\n" }; BEGIN();
      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.
      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.";
      

        All I can say in reply is that I will try to remember to remove that bit of personal cruft (along with several others that seems to get people hot under the collar around here:) from my code when I post. I will continue to use it in my own code though, as it seems to prevent more problems than it causes.

        I'm not dimissing the logic of your conclusion, only going with what I've found works for me.

        I agree the whole BEGIN block thing is..um...inconsistant is the politest word I can think of:) Another one of those 'special cases'. I'm quite disconcerted by the way all of the special blocks work, but I seem to be in a minority of one. There was a recent thread regarding the invocation order of BEGIN/END blocks where I expressed a contrary opinion and was roundly set upon. I guess this is another where my opinions are best kept to my self.


        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