a much better way would be to learn *before* you write anything.

I think the best approach is somewhere in the middle. Pick up a good introductory book (Learning Perl 3rd ed is the best IMO) read that, doing the examples as you go along (this shouldn't take you too long). Then start to work on your project and have a copy of Programming Perl 3rd ed around. Make sure to look up anything you're at all unsure of. Also pay very close attention to any user input and make sure to validate it (check it for acceptable contents, don't try and think of every unacceptable match) and just sprinkle on a bit of common sense and you should be good to go.

Most importantly, have fun. That's what it's all about, don't let anyone tell you different :).

This leads me to ask: Am I asking the wrong question?

I don't see how CGI should come into this at all. I expect this to be something that an admin (or me) would run from the shell prompt - I don't intend for it to be available on a web page or anything - the section:

use DBIx::Password;

my $filepath = $INC{"DBIx/Password.pm"};
[download]

Is only there to make sure that the correct version of the file Password.pm is used (if there is more than one for some odd reason).

Should I be trying to solve this problem some other way perhaps?

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.

Should I be trying to solve this problem some other way perhaps?

Yes. Don't store passwords in a Perl module. Put data in separate files, that aren't parsed by Perl. You could choose to use a database (which is quite easy to do in Perl), or a plain text file (a bit harder (even though most beginners seem to think plain text files are easy)) for your password storing.

Maybe I'm not understanding what your Password.pm does correctly.

Update - Nevermind me. I thought Vladinator was storing passwords in a module. "I know nothing about Perl" made me think he was a newbie that ill-named his module (You don't wanna know how many people store data in modules in the DBIx namespace, not realising that it is for DBI extensions). I didn't know about DBIx::Password on CPAN.

- Yes, I reinvent wheels.
- Spam: Visit eurotraQ.

I expect this to be something that an admin (or me) would run from the shell prompt

No reason not to validate the input. It's a good habit to get into even if your granting full privilledges to the user (and always question if this is neccessary, least privilledge is good, blah blah blah) .

And yes, if you're wondering, this post is just a thinly veiled attempt to cover up the fact that I didn't read all of your original post and just gave a carbon copy answer (it's still good advice though :).

Anyways, have a good one :)

Wouldn't a script be less vunerable to typo's and the like? Please, tell me the right way to solve this problem! If writing a script isn't it, I'm all ears. Either way, I need this functionality.

Did you actually read what I wrote, or was that a knee-jerk response I just witnessed?

I have no interest in changing the module. I want to write a script that uses the module, as is, to find a file that holds DATA, that we have to manipulate BY HAND on a regular basis.

Okay, you lost me completely. You use a module to find a file, yet the module is named DBIx::Password. What file does it find, and what data is stored in it? I'm sorry - I thought I knew what you meant, but apparently I do not, and your explanation didn't help much.

Did you actually read what I wrote, or was that a knee-jerk response I just witnessed?

I did read, but misunderstood. What exactly does your DBIx::Password module do?

Update - Nevermind me. I thought Vladinator was storing passwords in a module. "I know nothing about Perl" made me think he was a newbie that ill-named his module (You don't wanna know how many people store data in modules in the DBIx namespace, not realising that it is for DBI extensions). I didn't know about DBIx::Password on CPAN.

- Yes, I reinvent wheels.
- Spam: Visit eurotraQ.

DBIx::Password is not as bad as Handy::Dandy but it is close. The Makefile.PL is essentially an interactive config script which then writes the config - wait for it - *into a variable within Password.pm*. Yummy. No methods to change anything either. If you forget to change the permissions as suggested then anyone can read all the passwords. If you set it so that only the Server can read the .pm then anyone who can write a CGI can access it. It is pretty bad and tres tres insecure.

cheers

tachyon

s&&rsenoyhcatreve&&&s&n.+t&"$'$`$\"$\&"&ee&&y&srve&&d&&print