Okay, one concept at a time.

Consider these three statements:

    my $var1 = 0;
    my $var2 = '';
    my $var3;
[download]

These three variables have different values in them.

1. The first is a numerical zero^*
2. The second is a text value (which happens to be blank)
3. The third is undefined. Meaning, it's not zero, it's not spaces, it's not an empty text string -- a chunk of memory has been set aside for it but no value of any kind is associated with it.

^*The nuances of how the data is actually stored is not important right now, so for our purposes, calling it a numerical value is sufficient for the task at hand, even though it might not be technically accurate under the covers.

This last one works reasonably well with both arithmetic operations (treated as zero) and text operations (treated as blank), but there are places where Perl cannot reasonably assume what you mean.

Hash keys is one of those places; and you are using the variable in question as a hash key.

So you get warnings when using uninitialized variables in certain circumstances, like print statements or when used as a hash key.

So, to answer your question -- I don't know if my suggestion is the right thing to do. You know how you're a biology specialist but are new to Perl programming?

Yeah, the opposite for me. Perl I understand; but I have no idea what a fasta file is, why it's different than a slowa file, or what would be in one.

So -- just to help us along here, is there any chance you could put up maybe 5 lines of data from your fasta file, embedded in <code></code>tags?

This won't necessarily identify the problem, but it will help us see how the file is being used by the Perl script -- and that could lead to some insight. Maybe even an Aha!/Eureka! moment.

With that context, we might be able to answer your question in a more useful manner. There's just a few unknowns too many at the moment.