Long answer: I think that you should always reset the hash iterator before you use each() on a hash in a function.

I see no need to use each in this case:

sub find_in {
    my ($data_ref, $string) = @_;
    my $result = 'no result';

    my ($key) = grep /^$string$/i, keys %$data_ref;
    $result = $$data_ref{$key};
    return $result;
}
[download]

Update: condensed and with a modified data set:

sub find_in {
    my ($data_ref, $string) = @_;
    return $$data_ref{ (grep /^$string$/i, keys %$data_ref)[0] || '' }
+ || 'no result';
}
sub look_for_data {
    my %hash = ( A => 'axxx' , B => 'bxxx' , C => 'cxxx' , D => 'dxxx'
+);
    print "d: " . find_in(\%hash , 'd') . "\n";
    print "A: " . find_in(\%hash , 'A') . "\n";
    print "B: " . find_in(\%hash , 'B') . "\n";
    print "Z: " . find_in(\%hash , 'Z') . "\n";
}
look_for_data();
__END__
d: dxxx
A: axxx
B: bxxx
Z: no result
[download]

Update 2: Added ^ and $ anchors as per jhourcle advice.

Update 3: Same again.

Be careful with that regex:

(lc($name) eq lc($string)) and ($name =~ /$string/i) are not the same, as the regex will match any occurance of $string within $name (ie, substrings of $name, as well).

For the original poster -- have you considered using a case insensitive hash? See Tie::CPHash

thanks for the hint, concerning Tie::CPHash, might save me some work in the future.

Thanks for your answer.
actually i think there is never a _real_ need to use each, as you can always do it using keys. The thing is i like to use each, because deeply nested hashes tend to get a bit more readable through the use of each (imo).
But i guess in some cases where i use while each, your code might be a good inspiration.
By what you and japhy posted, it seems to me that the only reliable way of getting all elements is keys. As with each you will "never know".
I find it somehow strange that while (my ($key , $val) = each %hash) is the recommended way (perlfaq) for getting all elements from a hash as the behaviour can get so quirky rather quick.

oops. thanks and sorry. didn't find it when i looked for it in the archive.

use strict;

sub find_inB {
    my ($data_hr, $string) = @_;
    my $no_result = 'no result';
    return (
        exists $$data_hr{ $string }
            ? $$data_hr{ $string }
            : exists $$data_hr{ lc $string }
                ? $$data_hr{ lc $string }
                : $no_result
    );
}

sub look_for_dataB {
    my %hash = map { ($_, 'xxx'); } qw( A B C D );
    print "D: " . find_inB(\%hash , 'D') . "\n";
    print "A: " . find_inB(\%hash , 'A') . "\n";
    print "B: " . find_inB(\%hash , 'B') . "\n";
    print "B: " . find_inB(\%hash , 'B') . "\n";
}

print "# look_for_dataB:\n";
look_for_dataB();

__END__
# look_for_dataB:
D: xxx
A: xxx
B: xxx
B: xxx
[download]

well - for example this doesn't help if i don't know the case of the key-string, as i won't be trying all possible permutation of a String sTring stRing strIng STrING with an exists statement ...

Also it doesn't help me, when my hashkey is of type "What_I_am_looking_for Irrelevant_String", then exists also won't help me, as i don't necessarily know what the string Irrelevant_String is.

My Problem isn't that i am not finding the data in the hash, i was primarily confused by the behaviour of each which was caused by my lack of knowledge of the way it behaves.

(Posted it in part, in case sbd else has the same problem, so he can find the answer on the net).

True, though I was keying off your line which merely required

if (lc($name) eq lc($string)) {
[download]

I'd say the thrust is still valid, though, assuming you are the one constructing the hash in the first place. That is, why not, at the point you create the hash key, normalize it to lowercase with:

my %hash;
my $next_key = 'What_I_am_looking_for Irrelevant_String';
my $data_for_next_key = 'xxx';

$hash{ lc $next_key } = [ ($next_key, $data_for_next_key) ];

print
    "Value associated with '$next_key' is '",
    $hash{ lc $next_key }->[1],  # or $hash{ lc $next_key }[1]
    "'\n";
[download]

and now a test for exists would only even have to test for a lower-case version of the string_in_question. If your hash is at all sizeable, I'd think that using a little extra RAM to store the original key would be beneficial: you could avoid iterating through the keys every time you need to do this check.

This assumes that you don't have duplicate entries because of case, i.e. it will have to be okay that $hash{ aBc } clobbers $hash{ ABC }.