#!/usr/bin/perl

sub routine1 {
  # this routine's code here
}

sub routine2 {
  # another routine's code
}

1;
[download]

require "functions.pl";
[download]

--
tune

Abigail

Make a file named Module.pm in '/usr/home/you/modules'. This one should contain something like:

package Module;

require Exporter;
@ISA = Exporter;
@EXPORT = qw(dostuff);

sub dostuff
{
my ($dostuff) = @_;
return $dostuff
}

1;
__END__
[download]

You then call them by adding:

use lib '/usr/home/you/modules';
use Module qw(dostuff);
[download]

to your main program.

I disagree with using a 'main' subroutine. It is un-Perlish and serves no purpose.

--
Regards,
Helgi Briem
helgi AT decode DOT is

I'm not using a main function either, but consider doing so in the future since it may help trap scoping errors and eliminates global variables which is always a Good Thing(tm).

Just my 2 cents, -gjb-

Why do you want to split the subroutines into files? If you want to "encapsulate" the elements (to ensure that, for example, global variables don't "leak" between routines) you can do that within a single file by putting things in blocks:

    use strict;
    use vars ('$really_global_var');
{
    # First block, the main routine
    my($var_in_main);

    main();
    exit(0);

sub main
  {
    SubOne::sub1();
    ...
  }
}

{
    # Second block for the first set of things

    # Can also put it in its own package for further
    # clarity
    package SubOne;
    my($sub1_var);

sub sub1
  {
    $::really_global_var = 42;
    $sub1_var = 23;
  }
}
[download]

If you require a whole load of files then it makes it harder to ship. Of course if you have a number of scripts that each use subroutines then putting everything in one file won't work.

I've seen this approach a few times, and it makes for increased modularity I guess, but I don't love it.

What are the monks thoughts on this approach.
--

($_='jjjuuusssttt annootthheer
     pppeeerrrlll haaaccckkeer')=~y/a-z//s;print;
[download]