True, though I was keying off your line which merely required
if (lc($name) eq lc($string)) {
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";
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 }.
| [reply]
[d/l]
[select] |
We are experiencing communication problems :)
Thanks for all the time you took to show me some alternatives. The thing is: the reason why i posted isn't how to find a hash element, but that i had a problem with the use of &each, which i wanted to share with the rest, in case there are more out there who don't understand its correct use.
I already use those lowercased keys in diffrent parts of my programm, but in this case i refrained from using it, as this hash is generated by a general purpose parser, which i don't want to modify as it also is used in other sections of the programm. I also don't want to create an additional hash with the data reorderd in a diffrent way, as i already have about 10hashes in this subroutine alone, with data from diffrent files/subroutines which i have to compare inside this routine. Also, this function is called only for rare exceptions, and the amount of keys on the first hirarchy level of my nested hash has never more than 10 elements ...
(i am comparing the keys of that first level) .
Plus the Problem what i tried to explain to you before, that i don't know the values which Irrelevant_String might asume - its not fixed, and not under my control. It might be banana , gwbush, horse or Xzadd##fasdafa33. Like that i can't use exist. Of course i might create a new hash which has What_I_am_looking_for lowercased and Irrelevant_String trimmed from it as the new key and the original key stored in the array-ref as you showed in your above example. But that would be another hash, and in my case not worth the overhead (called seldomly).
As you probably aren't a telecommunication-telepath you couldn't know that. I just wanted to clarify, that this "finding the hash key" wasn't the central part of this node, but the reseting and not_reseting of the hash iterator, when one leaves a while-each loop through use of last or return, as this behaviour wasn't clear for me.
| [reply] |