I try to avoid string-eval wherever I can, because I don't like the security implications of it. Of course, it's unlikely that a module name like CGI; qx(rm -rf /)

You make an excellent point about the dangers of string-eval. Of course you need to de-taint the module-name before you eval it. Perhaps something like the following would help to assuage your fears?

#!perl -T
use strict; use warnings; # flame-resistant

print "module: ";
chomp(my $module = <STDIN>);

if ( $module =~ /^([A-Za-z0-9_:]+)$/ )
{
    $module = $1;
}
else
{
    die "Can't use $module: hack off, buddy!";
}

eval "use $module";
print "game over ($@)" if $@;
print "all clear\n";
[download]

The verbosity certainly rivals the package-name-to-file-name twiddling that you had to do, so neither way is preferable... :)

--
edan

Eh, considering that a use or a require does an eval, what exactly are you trying to protect yourself from? If a user can pass a module name of his choosing, you're doomed anyway, no matter what restrictions you put on the module name:

    echo 'BEGIN {qx {rm -rf /}}' > MyModule.pm
[download]

and then you hand 'MyModule.pm' to the program.

If the program is not running on behalf of someone else (like, uhm, 99% of the programs outthere), there's no security issue with string eval anyway.

Like I already discussed, avoiding string-eval is for when input comes from untrusted sources. For example, a module loaded by (hopefully tainted) data read from the internet via a form submission. There, the user can't create a module of their own devising on my local machine but still could run arbitrary code with your method. I know that the variant I propose is propably overkill, as I already said above, but on the other hand, it isn't much more code and will land in a subroutine anyway, if such a feature is needed but not provided by any of the *::Plugin modules.