No, writing a script utilizing a module makes absolute sense. After perusing DBIx::Password, I can see why you find it a pain. The module, when built, constructs a list of users, passwords, DBI drivers, etc. and modifies its own sourcecode, writing that data out to $virtual1, but after that file has been built, it's up to you to add new users, delete old ones from it. I suppose it's written this way because adding database users is a relatively uncommon activity, or at least it ought to be. In fact, why in the world are you changing database users on a regular basis? A good DB design does not require this. Rather, you should have general categories to which new users can be added. For example, you might have a three tier division, with, say 'administrator', 'trusted_user', 'guest'. When you get a new client you simply add them to the 'trusted_user' or 'guest' categories, just as you would to a *nix group. If they're sharing the same database, there's no reason for different passwords. <Update> atcroft pointed out in the CB that you may be allowing customers to create their own tables, for which multiple separate accounts would be useful. In this case, I would strongly recommend moving away from DBIx::Password and looking at a solution that separates your data (username/password strings) from your code. </Update>

That said, it sounds like what you want to do is to read the source for the module and rewrite it with new contents in an automated fashion. So, take a look at open, close, and look at some examples for reading contents from filehandles. As to specifying user options, look at Getopt::Std and Getopt::Long.