First off, you speak of "some of the things I use in every script". To me, that screams "config file". There are literally dozens of config file handlers on CPAN. My current favorite is Config::Std, but I've also used others, like Config::ApacheFormat, to good benefit. All that matters is that you pick one and are consistent.

Second off, you say "my scripts pretty much do the same thing". Then, you very nicely list each one and ask "Does it make sense to build a genric script ...?"

My answer to that question is "No." You don't want to build a generic script, you want to build a general-purpose library. For example, you always set up an ftp connection first. Ok, create a connect_ftp() function and house it in some library.

Why do it that way? Well, there's a lot of reasons. The biggest reason from a software engineering standpoint is testability of your library. You will want to verify that each piece works correctly on its own. You can't do that without a well-defined interface. But, for these little scripty-doos, you may not have the time for all that jazz.

The most important reason for you is that you will be asked to write a quick one-off script to do something just like what your generic script would do, but ever so slightly different. Maybe, it needs to process files that have already been downloaded. Or, you might want to run the file processing without the DB connection. Or, you want to create a report from the DB. I don't know and, more importantly, neither do you. If you have all your different actions in a tinker-toy/lego type of setup, it becomes easy to write that one-off script.

So, here's what I'd recommend:

• Pick a config file module from CPAN and use it religiously.
• Create a repository of useful functions. Call it "Useful::Stuff" (filename of Useful/Stuff.pm). It will look something like:

  package Useful::Stuff;
  
  use 5.6.0;
  
  use strict;
  use warnings;
  
  our $VERSION = 0.01;
  
  use base 'Exporter';
  
  our @EXPORT_OK = qw(
      connect_ftp
  );
  
  sub connect_ftp {
  }
  
  1;
  __END__
  
  =head1 NAME
  
  =cut
  [download]

• Within this library, use as many CPAN modules as you can. You don't want to write anything more than you have to.
• Note the POD at the end. Document the crap out of this thing.
• Note the $VERSION variable at the top. You will want this thing in version control.
• Don't export variables. Only export functions.
• Use @EXPORT_OK, but provide useful %EXPORT_TAGS so you can do something like use Useful::Stuff ':standard'; and have a standard import list.
• I'd put this into a distribution suitable for CPAN (though you won't upload it). That way, when you install it on a new box, it will take care of all the prerequisites (like DBI, DBD::whatever, Net::FTP, etc). I'd use Module::Build and avoid ExtUtils::MakeMaker like the plague.

Please ask if you want more information on any point above or if you have questions about what you're doing. :-)

---

---

• Are you posting in the right place? Check out Where do I post X? to know for sure.
• Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:

  <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>

• Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
• Want more info? How to link or How to display code and escape characters are good places to start.