Why don't you use your currently favourite module, Parse::RecDescent? :) Seriously, you seem to be processing a grammar, to produce an interpreter. I'm no expert o nthat module, so I won't dig into this too deeply. I'm sure somebody else will. :]

As for critique on your current code, here are some incoherent thoughts. Most of all, I don't like your use of symbolic references. I can assume this isn't your actual code, that your syntax is actually described in an external datafile. Still, there's no need to keep the data in this way. I would use anonymous subroutines instead of the functions and method calls. Like:

$Commands{'log'}{'function'} = sub { createlog(shift) };
$Commands{'modules saveall'}{'function'} = sub { savemodules() };
$Commands{'modules loadall'}{'function'} = sub { loadmodules(shift) };
# extra example for module call:
$Commands{'foo'}{'function'} = sub { Bar->foo(@_[0, 1]) };
[download]

You can generate these subs from strings using eval:

$code = 'print "Hello, $name!\n";';
$sub = eval "sub { my \$name = shift; $code }";
print "Ready to test:\n";
$sub->('world');
[download]

You get a compile time check of all code, this way — "compile time" meaning at the time your data structure gets filled.

You do have to be careful, if this code comes from an external source, to check that it doesn't contain malicipous code.

Also, use qr// for your patterns. Again, you get a compile time checks of all the patterns, plus it'll be faster at runtime.

I'm quite unhappy on how you actually do the parsing, but I'm not sure how I'd tackle that. I think I'd use (precompiled) regexes, not substr(). What if somebody typed "logic", would you try to do the "log" action? What if somebody typed "modules  saveall", would it fail to match? Still, if you don't want to use regexes, you definitely need to extract the words from the command line first, and then check if these words match.

And I think I would group the "modules saveall" and "modules loadall" under one common processing umbrella, "modules". For that, you'd have to have two subpatterns, one for each option.

As a summary... your data structure seems to have a bit of redundany, doesn't it? All you really need is the syntax/pattern on one hand, and the function on the other. The number of parameters is determined by the pattern.

Perhaps use Parse::RecDescent would still be the simpler solution... :)