First off, you speak of "some of the things I use in every script". To me, that screams "config file".
You don't want to build a generic script, you want to build a general-purpose library.
And, after he has done that, he wants to build a generic script using that library. Such a tool would be the sensible place to make use of the aforementioned config file, by the way.
Generally you want to avoid creating a multitude of tools that all do essentially the same thing for all the same reasons you avoid duplication of code elsewhere. It's often easier to cp mytool mynewtool and begin making changes but in the long run you end up with a messy toolbox filled with buggy, poorly documented, out-dated, narrow purpose tools.
In other words, create power tools. When it comes to software, it doesn't make sense to build the equivalent of 10 different screwdrivers and a hand-drill when you can build a power drill that takes options like --bit-size, --masonry, and --phillips-head. When you do build multiple tools, build them for different purposes. In the OP's case, for example, it might make sense to have one tool that retrieves the files and another to collate the data and insert it into the DB.
-sauoq "My two cents aren't worth a dime.";
In reply to Re^2: Of strict, globals, packages and style
by sauoq
in thread Of strict, globals, packages and style
by jimbus
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |