You haven't shown the entire statement that begins on line 416, presuming it's that "if".

Keep in mind that a statement (including a chain of elsifs) is all considered to begin on its first line, no matter how many lines it spans. So you probably have a <= comparison in some elsif branch that you aren't showing, and one side of that is undef, just as the error says.

You'll see that the warning message cites line 4. Simple rule: when a warning points to an "if" statement and makes no sense for that line, check each of the "elsif" statements that relate to that line.

With these in place, you can tell where the "undefined" warning comes in the sequence of execution.
It's messy, but you only have to look at it once, for a quick reality check. The debugger is another way to do this, which could be easier or harder, depending on your inclination to switch over to the debugger mindset.

Are sure that each element in @_ is always a defined value? If you know that some elements may be undef and you expect that but can't bear the uninit warnings, just disable selected warning around the block in question. Like,

So, if $_[$i] was undefined where $i is at somepoint of iteration, the execution would not even reach the first if.

And yes, I'd really like to know what happens after that undef $_[$x]. This is not the usual way in constructing multi-level loop. But beyond what you've shown and asked, I sort of believe that the problem lies on your program design. The first obvious indication to me is you need to check on /^(.+?)\.(zip|t?gz|tar|bz2?|tbz)$/i twice. The second is the inner loop on the same array.

Here's another hint. Working directly on elements of @_ will often give you unexpected results, since $_[$index] is a just reference to the original argument of the corresponding element.

Open source softwares? Share and enjoy. Make profit from them if you can. Yet, share and enjoy!

Yes, it's kind of weird, but it's a work in progress. The secondary loop and the part about compressed files were shoehorned in there to deal with problems removing temporary directories. You're right that I should clean it up and use a different array variable other than @_, even if just for readability.