As a side note to my reply, one of the "challenges" of using Perl is that, in our environment, we can't bring in "external code" (i.e., code that we, ourselves, haven't generated) other than the Perl distrubition package itself.

The consequence of most pain to us is that we can't really avail ourselves of rich set of tools from CPAN...a most distressful situation...but our security and strict configuration controls necessitate this sad state of affairs.

However all is not entirely lost, as we *can* bring in code we've developed and/or tested ourselves. That is the paradigm that allows to, for example, develop and test code on the PC and then port to the Solaris.

So, we can, for example, download CPAN modules, test them, develop with them and then port them over to the Solaris and simply include them (in the form of saving them in the same directory as our scripts as *.pm files) as we do the libraries that we, ourselves, have created.

That works surprisingly well most of the time but it has the disadvantage of being libraries that are not "installed" in Perl...i.e., that aren't automatically gathered together with their other "required modules" and made automatically known to our apps.

So we have to do the painful task of figuring out all of the "required modules" and then figuring out all of those modules' "required modules", etc. and then loading them into our app's directory(ies)... actually we have a standard library directory that all of our apps know to use and is in our path statements.

Hence, we tend to only use the CPAN modules that meet our needs AND that don't require any other modules (at least any other than the ones that come pre-packaged with the Perl distribution).

Unfortunately, of late, we have found a couple of CPAN modules that we'd really like to use...but they seem to have an unending "deep-dive" set of "required modules". That is a real "frowny face" for us.