The code given has syntax errors in it, but setting those aside: It-Works-For-Me(tm). Here it is with typos removed:

BEGIN { 
        my $mod_path = "/home/tboyd/lib/site_perl/5.6.1/Tools/";
        my @mods = glob("$mod_path*");
        for (@mods) {
                require $_;
        }
}
[download]

It should be noted that require is different from use in that use calls the module's import method and require does not. So, this could cause problems later on if you expect symbols to be imported (or these modules do something else nice for you in import).

You may also want to change your glob to end in *.pm if you only want those files as there could be other files in the directory that aren't perlish.

For me, your code results in

Can't locate C:/Perl/site/lib/ACME in @INC (@INC contains: C:/Perl/lib
+ C:/Perl/site/lib .) at C:\Dokumente und Einstellungen\foo\Desktop\t.
+pl line 10.

BEGIN failed--compilation aborted at C:\Dokumente und Einstellungen\fo
+o\Desktop\t.pl line 12.
[download]

I just tried to use eval to trap some nasty error messages and I got away with it -- I highly doubt whether this is legal, though:

#!perl

use strict;
use warnings;

BEGIN {
   my $dir = "C:/Perl/site/lib/";
   my $r;
   for (<$dir*.pm>) {
      /([^\/]+)$/ && ($r = $1) or next;
      eval { rquire $_ } unless ($r and $INC{$r});
   }
}

use Data::Dumper;

print Dumper \%INC;
[download]


Anyway, I hope this helped the OP.
CombatSquirrel.

---

Entropy is the tendency of everything going to hell.

The error you point out is part of the reason I suggested changing * to *.pm. Directories won't load very happily. Although, in this case we could add this instead of the *.pm:

require $_ unless -d $_;
[download]

But, with this solution, we'd still run into problems if there are other odd files like READMEs or something else that got stuck in the directory we are scanning.

It would be just a file Index.pm and look like this:

require X;
require Y;
require Z;
[download]

Unfortunately I don't have anywhere to test that right now.

I could do that, but the solution I'm looking for will allow me to put modules in the directory (i.e. a new module called Module4.pm) and then have the script automatically recognize the existence of this new mod. I'd like to have avoid the the maintence of an index.pm ;) -CUBErat

I'm sorry, but something about this train of thought makes little or no sense.

... the solution I'm looking for will allow me to put modules in the directory (i.e. a new module called Module4.pm) and then have the script automatically recognize the existence of this new mod.

What I don't understand is: if you create or install a new module, and you want to use it in an existing perl script, don't you have to edit that existing script anyway, to add whatever logic will be invoking the objects/methods/etc being provided by the new module? And if you have to edit an existing script anyway, why not go ahead and add the specific "use Newmodule;" statement at the top? Why is it a problem to do that?

If I had to maintain a setup like yours, where all the modules in a given location are being loaded into scripts implicitly, I think I might end up losing sanity... Some modules do not export their function calls by default, and this is done, in part, so that the programmer who uses the module has to declare specifically when he is using a particular function from the given module. This is good for maintenance, because it's easier to keep track of where stuff comes from.

Update: Another reason why modules don't export by default is, of course, to guard against the inevitable collisions in the symbol table when two separate modules happen to export the same name. I suppose that if you're in a situation where your scripts are being created automatically by some other script(s), it might make sense to have this sort of "automatic scan and load" operation over a whole module directory -- but if you're doing that, it still makes more sense for the auto-generated script to have all those specific "use ModuleN" statements spelled out programmatically at the top. Why not?