Shell scripting

Many trivial scripts, over time, morph into not-so-trivial scripts.
Call it "scope creep" if you'd like.
I can hear folks right now, "Well if you put a little more thought into it in the design phase..."
I'm a little like that myself. But even the best of us find ourselves in that place once in a while. Less often as we gain experience, but even so - we still have those scripts we wrote when we had less experience. And there are other factors:

Sometimes you just don't know all the requirements ahead of time. This happens a lot when you're just learning a new field.
Sometimes the requirements change, sometimes a lot, long after the script was "finished". Now you get to go back and maintain your own code and you remember why you don't cut corners with comments and documentation.
Sometimes you write a script that is so useful you end up using it all the time and you decide to make it just a little more pleasant to use. Add a feature here, a feature there.
And sometimes you really -didn't- put enough thought into it in the design stage... or you didn't even -do- a design phase because, you know, it's just a little script. And sometimes that's ok - but sometimes it bites you in the butt.

However you got there, your once-trivial script isn't so trivial any more and now you have to think about any or all of the following (and maybe other things that I haven't imcluded here, but that's another topic):

help screens / help text
version tracking / revision history
default config handling
config file handling
command line argument processing
console output filterable by "debug level"

As with so many other things in life, it's simpler to handle these things if yuo do so in a consistent manner. One way to achieve that is to build yourself a script template and start new scripts by making a copy of the template and adding project-specific functionality to it.
If you know at the outset that a new script is going to be non-trivial, start the project by allowing for all of these things, even if you might not use all of them. If you catch a trivial script right as it's about to explode into a monster, you can fairly simply shoehorn it into your template, then unleash it to grow as it needs to... but keep it within the framework of the template. If your template includes some parts that aren't used (yet), that seems like a small price to pay for the savings in development effort. If you've got a script that has already got some complexity to it, it -might- still be worthwhile to apply your template to it, depending upon how the original script was written.

My template, which I'll probably post here at some point, handles the features listed above as follows:

help screens / help text - are simply specially tagged comments
revision history - is simply another help screen
the current version number is abstracted to a vaiable and is shown in the help screens
default config parameters are hard coded and contained in variables
config files are optional but, if present, override the hard coded defaults
command line arguments are optional but, if present, override both hard coded defaults and config file settings.
command line arguments can be either name=value pairs or simple present/not_pressent flags
console output is abstracted to a function that allows masking by verbosity level ("debug level)

To parse command line arguments, I use a bit of code that was originally written to parse linux kernel command line arguments as retrieved from /proc/cmdline
More text soon - I'm taking a break to update this argument parsing functionality.