#!/usr/bin/perl -w
use strict;

my $minlen=6;
my $maxlen=10;

use Crypt::GeneratePassword qw(word chars);
my  $word = chars($minlen,$maxlen);
print "$word\n";
[download]

It looks like you've posted some code that makes up passwords -- I haven't tried it -- and shown roughly how you call it. Your code fragment isn't complete -- I am guessing you have a list of users and want to create unique passwords for each user, but I can't tell.

Maybe you want to do something like this

my @users = qw/Albert Bob Charlie/;
foreach my $thisUser ( @users ) {
  my $password = makePassword();
  my $sql = "INSERT INTO login (login, password)
             VALUES (?,?)";
  my $sth = $dbh->prepare($sql);
  $sth->execute($thisUser, $password);
}
[download]

First off, your code is pretty darn long, highly inefficient, ugly, and can be shaped up a bit. But that's not why you are here. But I want you to understand -- when debugging bad code, it's harder to find the problem. Hence this is why (so far) no one has figured out what your problem is....we're lazy. Give us clean code, and we'll jump to the challenge!

My eyes immediately look to the placement of srand -- seed random number generator. This needs to be called at the top of the application, not inside the random_number function. Reseeding the random number generator between each call isn't good. In fact, it's a very bad idea for security reasons. The time xor'ing with the PID is something I haven't seen before, I assume you think there is a chance of a random number generator being started at the same time and you don't want them to coincide. I find this very odd for a database program -- so most likely this code was copied and pasted from somewhere. If it were me, I'd rewrite this whole thing from scratch. It's a maintainance problem and better password routines exist...much better routines that actually make sense to read.

Just guessing here, but I bet you are feeding the same value to srand every time. Check it out.

You are using an SQL-ish database to store names and passwords, so it should be the case that you can (and should) apply a "UNIQUE" constraint on both the name and the password fields -- this way, it you try to insert a row that uses a value already present in the table, the database will reject it, and the insert statement will fail.

This would also mean that you need to work out how to check and handle the return status of the statement execution. Sometimes, the default behavior with DBI is to "die" when something goes wrong, but the way to alter and control this is explained in the DBI man page. (Yes, that man page is long and complicated, but if you're going to use DBI, you need to need to read the man page.)

Of course, you could also take the time to check for the existence of a given user name in the database before you try to insert it -- e.g. (using the table and column names that you seem to have in your database):

my $sql = "select login from login where login like ?";
# (I would have used different names for table and column)

my $sth = $dbh->prepare( $sql );

my $newname = "whatever";

$sth->execute( $newname.'%' );
my $likenames = $sth->fetchall_arrayref;

# update: remembered that fetchall_arrayref returns AoA,
# so added map to get actual field values into grep
# (also remembered to include the "execute" step above)

if ( grep /^\Q$newname\E$/, map { $$_[0] } @$likenames ) {
    $newname .= "00";
    while ( grep /^\Q$newname\E$/, map { $$_[0] } @$likenames ) {
        $newname++;
    }
}
[download]