The trivial answer is to just rename it, and make sure it returns a true value (this is usually done by making sure the last line of code is "1;").

More generally you probably want to:

• Move any functionality that is not already wrapped in sub {...} into subs, allowing the subs to be triggered explicitly by the caller.

• Factor out any use of input from STDIN and output to STDOUT, so that instead it gets its input from the caller script, and returns its output to the caller via function calls.

Here's an example script...

# greeting.pl
print "What is your name?\n";
chomp(my $name = <STDIN>);
print "Hello, $name!\n";
[download]

You could refactor it into a module like this:

# Greeting.pm
package Greeting;

sub say_text {
  my $handle = shift;
  print $handle "$_\n" for @_;
}

sub read_answer {
  my $handle = shift;
  chomp(my $answer = <$handle>);
  return $answer;
}

sub question {
  return "What is your name?";
}

sub response {
  my $name = shift;
  return "Hello $name";
}

1;
[download]

Which could be used like this...

# greeting.pl
use Greeting;

my $in  = \*STDIN;
my $out = \*STDOUT;

Greeting::say_text($out, Greeting::question());
my $name = Greeting::read_answer($in);
Greeting::say_text($out, Greeting::response($name));
[download]

After that, something to consider is making your code more object-oriented, thus allowing people to subclass it, overriding parts of its functionality.

Is it a .pl file or a .PL file? .PL files, in the build process, are executed to generate the resulting file (.pm, .pl, .tmpl, etc) in the blib during the build process (see PL_FILES in ExtUtils::MakeMaker or Module::Build::API).

Update: is this related to Problem with PDL module?