Data::UUID will create a unique number, without having to know which id was last assigned. The number might be too big for you, though.

Update: This module is a standard implementation of jZed's suggestion.

Inline::Files sounds like a good idea. the UID number attribute will be used for the posixAccount object class (unix logins), so i'm pretty sure it actually has to be a number. using an ancillary file would've been my other option, although i think if i can store the uid in the script it might be the most convenient.

Wait a tic...the last time I added Unix accounts, I don't remember the need to specify a UID. The system takes care of this automatically. Am I missing something?

thor

Feel the white light, the light within
Be your own disciple, fan the sparks of will
For all of us waiting, your kingdom will come

# Get current file name
$filename = __FILE__;

# get old UID stored after __END__
$uid = <DATA>;
chomp($uid);
print "This script has been run $uid times $/";

# increment UID
$uid++;

# open current running file
open(THIS_IN, $filename) or die "Could not open file";
@code = <THIS_IN>;
close (THIS_IN);

# Store new UID in last line of this code
$size = @code;
@code[$size-1]=$uid;

# open current running file
open(THIS_OUT,"> $filename") or die "Could not output to file";
print THIS_OUT @code;
close (THIS_OUT);
 
__END__
0
[download]

The idea is great and it works nicely, but only if you are sure that you are the only user of this script. It will not work in a web-server environment or --heaven forbid-- in a mod_perl environment for instance where this same script could be called by more than one client at the same time as it has no protection against such classical race conditions.

I know "multiple concurrent user safety" wasn't part of the specs of this question, but I thought it would be good to give a word of warning here anyhow. I've been bitten before by race conditions when using cook-book (aka cut-and-paste) style programming before.

CountZero

"If you have four groups working on a compiler, you'll get a 4-pass compiler." - Conway's Law

I know "multiple concurrent user safety" wasn't part of the specs of this question, but I thought it would be good to give a word of warning here anyhow. I've been bitten before by race conditions when using cook-book (aka cut-and-paste) style programming before.

I learned one lesson in my intro to concurrency course: "Concurrency is hard." There are few, if any, concurrent debuggers in existance ( one grad student was working on one, with some limited success), and the very convenient rule that states "if I run the same program, with the same inputs, I'll get the same output" goes out the window, because other programs can interfere.

Avoid concurent programs when you can: when you can't, swear loudly and quadruple your delivery date.
--
Ytrew

my $id = crypt($firstname,$lastname);
[download]

Well, if the OP was satisfied to have unique strings, he could have taken the $firstname.$lastname in the first place. Which actually has a better chance of being unique than your suggestion - as it will return the same string for "John Black" and "John Blueberry".

If your on windows, you could store it in the registry and then call it each time you need it within your perl file.

Optionally you can use any database module from CPAN to save this data to a database DBD::SQLite, DBD::MySQL, DBI, etc.

Hope this helps

use strict;

my $uuid_store = '/tmp/.uuid_store';
my $MY_UID=1;

if (-e $uuid_store) {
    open INHANDLE, "<$uuid_store" || die "Can't open $uuid_store for r
+ead\n";
    my $var = <INHANDLE>;
    close INHANDLE;
    $MY_UID = int $var;
}

print "The uid you are looking for : $MY_UID\n";

open OUTHANDLE, ">$uuid_store" || die "Can't open $uuid_store for writ
+e\n";
print OUTHANDLE ++$MY_UID;
close OUTHANDLE;
[download]

Output:

% perl gen_uid.pl
The uid you are looking for : 1
% perl gen_uid.pl
The uid you are looking for : 2
% perl gen_uid.pl
The uid you are looking for : 3
% perl gen_uid.pl
The uid you are looking for : 4
% perl gen_uid.pl
The uid you are looking for : 5
% perl gen_uid.pl
The uid you are looking for : 6
[download]

#!/usr/bin/perl

use strict;
use warnings;

sub get_next_number {
    open FILE, "<$0" or die "1:Could not open file : $!\n";

    my @lines = <FILE>;
    my $n = $1 if ( @lines[scalar @lines - 1] =~ /#NEXT_UID=(\d+)/ );
    my $m = $n + 1;
    pop @lines;
    push @lines, "#NEXT_UID=$m\n"; 
    close (FILE);

    open FILE, "+<$0" or die "2:Could not open file : $!\n";
    print FILE $_ foreach @lines;     
    close (FILE);    
    return $n;    
}

my $num;
$num = get_next_number();
print "Next available number is : $num\n";

$num = get_next_number();
print "Next available number is : $num\n";

#NEXT_UID=14
[download]

#!/usr/bin/perl

use strict;
use warnings;

#My changeable variables
#NEXT_UID=38
#NEXT_FLUFFY=6

sub get_next_number {
    my $var = shift;
    my $n = -1;

    open FILE, "<$0" or die "1:Could not open file : $!\n";
    my @lines = <FILE>;
    close (FILE);

    for my $linenum ( 1 .. scalar @lines - 1 ) {
        if ( $lines[$linenum] =~ /#$var=(\d+)/ ) {
            $n = $1;
            my $m = $n + 1;
            $lines[$linenum] = "#$var=$m\n";

            open FILE, ">$0" or die "2:Could not open file : $!\n";
            print FILE $_ foreach @lines;     
            close (FILE);    
        }
    }
    return $n;
}

my $num;
$num = get_next_number("NEXT_UID");
print "Next available number is : $num\n";

$num = get_next_number("NEXT_FLUFFY");
print "Next available number is : $num\n";
[download]

When you create an LDAP entry, it is assigned a Distinguished Name attribute (DN) -- this is a unique identifier for that LDAP entry.

The LDAP server itself has these DN's stored at that point, there's no reason to store them separately for your script -- they can be retreived at any time.

However, if you're dead set on storing unique identifiers, store the DN's in a hash for later reference. I like to use Data::Dumper to dump the hash into a data file for later reference and update.

Cheers,
Matt

• Well, if you use "cn=surname firstname,ou=..." as a DN, there might be the problem if there are two persons with the same name in the same ou... so an additional really unique id might be helpful (at least to make DN really unique): "cn=surname firstname uniqueid,ou=..." (or even think about using this uniqueId as cn... but that might cause problems with certificates...)
• If you want to do a periodic data synchronisation to different data sources, you need something constant... and a person's name doesn't need to be constant (e.g. in case of marriage).. so for meta directories, I often add a unique attribute to the ldap object which can also be copied to other data sources to get a link to objects in that directory

The way I prefer to use is to enhance the ldap schema by another objectclass (e.g. lastUniqueIdentifier) which contains among others the attribute an attribut where the last used unique identifier is saved (e.g. lastUniqueUID). This way I can use it from several synchronisation jobs...

Best regards,
perl -e "s>>*F>e=>y)\*martinF)stronat)=>print,print v8.8.8.32.11.32"

From the perl LDAP FAQ:

Every entry in a directory has a Distinguished Name, or DN. It is a unique Entry identifier throughout the complete directory. No two Entries can have the same DN within the same directory.

On the other hand, a relative distinguished name (RDN):

Every DN is made up of a sequence of Relative Distinguished Names, or RDNs. The sequences of RDNs are separated by commas (,). In LDAPv2 semi-colons (;) were also allowed. There can be more than one identical RDN in a directory, but they must have different parent entries.

I see your second point. However, I suppose it depends on how you're handling records -- in the event of marriage, for example, you could look at it as one LDAP entry being deleted and a new one created. That's fine if you don't care about tracking the history of name changes.

Cheers,
Matt