caller EXPR
    caller  Returns the context of the current subroutine call. In sca
+lar
            context, returns the caller's package name if there is a c
+aller,
            that is, if we're in a subroutine or "eval" or "require", 
+and
            the undefined value otherwise. [....]
[download]

As pointed out you really don't want to do this, but here is how anyway* ;-) This only works if you use the module not if you require if as when you use a module the modules import() method is called at the start of proceedings. This is not true for require when import is not called.

package MyModule;

use strict;
use Exporter;
use vars qw($VERSION @ISA @EXPORT $MOD_CALL );

$VERSION     = 1.00;
@ISA         = qw(Exporter);
@EXPORT      = qw( func1 );

sub func1  { return reverse @_  }

sub import { $MOD_CALL++; }

CHECK{ print $MOD_CALL ? "Called as a module\n" : "Called as a script\
+n" }

1;
[download]

On the rare occasions I have made a module a stand alone executable (usually for all the wrong laziness reasons) I have just used the presence of values in @ARGV to initiate script like behaviour. Generally you want to pass some data to a script anyway......

if ( @ARGV ) {
    print "I'm a script!\n";
    # do stuff
  exit 0;
}
# only get to here if you we are a module
[download]

* Recall the story about getting enough rope to hang yourself?

I do this all the time. Nearly all my modules have the skeleton:

#! perl -slw
package MyPackage;
...

return 1 if caller;

package main;
use Devel::StealthDebug;

our $ITERS ||= 10;
our $OTHER ||= 'default';

## run test code here
[download]

That allows me to embed the unit test code for the module directly into the module itself, keeping it all together.

The testcode then also serves as sample code for users (should any of my half-baked ideas ever get refined enough that I feel able to let it loose on the world :).

package My::Module;
use Getopt::Long;
sub process {
    local @ARGV = @_;
    # handle command line or named parameter options:
    GetOptions(...) or die ...;
    # here follows the rest of the script
}

return 1 if caller;

# This is executed only in "script" mode:
process(@ARGV);

# In "module" mode I have to write:
#   use My::Module;
#   My::Module::process(-bla => "foo", ...)
[download]

In the Python world, the sentiment is exactly the opposite. I remember reading in "Programming Python" this common idiom:

#!/usr/bin/env python
# module mymod2.py

def cube(n):
   return n ** 3

# when 'import'ed, __name__ is 'mymod2'
# when executed, __name__ is '__main__'
if __name__ == '__main__':
   if cube(15) != 3375:
      print "Error, cube(15) is not correct"
[download]

_____________________________________________________
Jeff japhy Pinyan, P.L., P.M., P.O.D, X.S.: Perl, regex, and perl hacker
How can we ever be the sold short or the cheated, we who for every service have long ago been overpaid? ~~ Meister Eckhart

You could also check the value of $0. If your module is executed rather than imported, it will return the name of the module. Otherwise it will return the name of the script that imported it.

Brad

Thank everybody for the replies.

I was looking to what user bgreenlee replied.
I do not think it is that terrible to have, on occasion and for private use,
a module that is "require" as this is more similar to DLL,
that can also be started from command line or "system"

Solution works like charm.
If loaded as stand alone, the suffix is .pm. If 'required' then the suffix is .pl all that is needed then


if ($0 =~ /\.pm$/i) {
 # execute stand alone
)
# fall thru for module.
[download]

Thanks again for all replies.

Of course, that's also the least robust solution of the four.

Makeshifts last the longest.

The Parse::RecDescent does somthing similar to this with its import mechanism to generate a precompiled dump of a grammar. You might look at what it does.

print "I'm a ".($INC{"mod.pm"} ? "module" : "script")."\n";
[download]

fergal@linux:~> perl mod.pm
I'm a script
fergal@linux:~ perl -e 'require mod'
I'm a module

I too have occassionally hidden test code in my modules, though not as cleanly as BrowserUK

In the fine tradition of TMTOWTDI, note that $0 doesn't change, but __FILE does, as you go from x.pl to x.pm, whether by 'use' or by 'require'.