Just a couple of comments...

The above suggestion is good advice, but I never liked the way that perl's -i option worked. One problem is that if you accidentally run your script twice you've just blown away your originals. Also, it's not 'transactional'. For some edits I want to be able to die and not have the original file change. For quick-and-dirty operations it can work well, but I wouldn't recommend using it for a massive editing process like you're describing. Rather, I would recommend that you:

• First make a backup of all the scripts you want to edit.
• Edit the (backup copy of the) files.
• Verify the changes are what you want.
• Install the new versions of the files into their original locations.

Making the back-up copies can be done easily using the --parents switch to cp, i.e.:

mkdir backups
find ... -exec cp --parents '{}' backups ';'
[download]

and this will preserve the parent path of the found files.

The other comment I have is that if you have several hundred files to edit, it might be helpful to reconsider how they are organized. It seems that your scripts are organized by <verb> <noun>, i.e. the script is the verb and the thing to act on is passed as an argument. You might look into changing this around so that the noun selects the script and the action is supplied as an argument. So instead of running:

$ start bgs
[download]

you would start up the bgs daemon by running:

$ bgs start
[download]

This will make your scripts more 'object oriented' and place similar concerns in the same script. Also, when you deploy a new version of the bgs daemon, you wouldn't have to edit all the 'start' scripts to include the new bgs code, you would just be replacing one bgs control script. Anyway, it's something to consider to see if it's applicable to your situation.