You can do it with use or require. Making your common subroutine code into a library (aka module) is the accepted way. See Simple Module Tutorial for sample code that shows you how. It is really very easy.

tachyon, this is great thank you! But I am still trying to understand this. Where do I want to set this up at, in my MAIN program where the file is created or in the subroutine file where the actual work is to be done? Here are some specific questions: how does the calling program ( call the remote files subrouting) know based off your use vars? Is there a mored detailed man page I can read and maybe I will answer my own questions! thanks derek

The typical construction of a perl widget is to put most/all your subroutines in one or more modules. These modules are your 'subroutine files'. You can save them anywhere. In your script you "use lib '/my/modules/are/here'" to tell Perl where to look for your modueles and then use whichever of your modules you want. Typically the subroutines in one module all relate to one sort of thing. For example DBI is a module for database accesss, Digest::MD5 gives you MD5 hashing.....

There is plenty of info in the perl docs. See perlman:perlmod perlman:perlmodlib perlman:perlmodinstall perlman:perlnewmod

cheers

tachyon

While there are several ways that you can get around creating a module and doing use Mymod, it's not really a wise thing to do for several reasons. The main reasons are:

1. If you have a look at many of the modules on CPAN, they do a lot of strange, interesting, and sometimes evil things... internally. But since they are properly-built modules, the calling code doesn't have to worry about this. Scoping your variables properly will achieve most of this as well, but making the module is better.
2. do "filename.pl" assumes you know the name and location of the file. use package works based on @INC, which you can change, and the package name, which you control. (Yes, the filename still comes into play, but it's a bit cleaner.) This means it works in Windows and Un*x, since you don't have to use system-specific paths/delimiters/conventions.
3. It's kind of silly to circumvent use and require. They were designed to do what you want, and work well. C'mon! Everybody's doing it. You want to be cool, don't you? ;-)

Seriously, though, when you consider that h2xs does most of the prep work for you, making a module out of a sub is pretty much cut, paste, change a few things in the header, save, done.

--J

   eval `cat subroute_file.pl`;

eval `cat subroute_file.pl`;
[download]

Why would you do that when the built-in function of do is defined as that, only better?

-- Randal L. Schwartz, Perl hacker
Be sure to read my standard disclaimer if this is a reply.

....and evaluate why would you do that when you should be required to use the lovely module architecture ;-)

As merlyn notes do is better than eval cat which is not portable.

cheers

tachyon